Discussion of "Patches" repository guidelines

[The Headacher]

1- Is doing a major upgrade of core libraries with a release cycle (i.e.: gtk+2, glib2) was a good idea or not?

I'd rather stay with the latest stable Slack versions of those libraries if possible, or Slack current if we really have to upgrade.

2-  Should such upgrades should go into patches so that anyone who does a slapt-get --upgrade gets them or rather should they be in a separate repository with patches reserved for security patches and bugfixes and

Well, at least they shouldn't go into patches, that much seems obvious to me now.

3-  Since so many manjor upgrades to 5.8 have been offered should VL respin the Standard ISO and call it VL 5.8.1. or something, including all the patches to date since they are tested

I'm not sure what would be the benefit of this. If we wait a few weeks/months we can start playing with slack 12 and apply what we have learned with VL 5.8 on VL 6.

2. these packages should have been put into the Gnome folder in the 5.8 repo, and that is where I understood they were going to be put.

Let's please watch out for creating a lot of different repo's, that's very Debianesque and juist plain confusing (Last time I tried some Debian based distro I even needed to add some weird repo for the Nvidia driver, the binary didn't compile on it).. I mean, just for Gnome is fine of course, we'd better watch out for fragmenting the repo's too much though.

[Darin]

why not have 2 branches...one is testing and the other is normal....now you can move the testing-updates over to normal pretty easily...as for the foundation of the branch...why not use the same as a the package was made for..lets come up with a revised skeleton for kde...or even use the repo branch to be the same...makes where to put packages alot easier as you can have gnome or any other window manager in a window manager section....simplicity is the answer especially with people contributing packages..just my 2 cents on how to clear some confusion in things

[Joe1962]

I agree too many repos is complicated, but too few is a problem, so I guess we need to find a balance. Maybe we need to set up an "experimental" repo for stuff like that gtk upgrade? Then we can keep "patches" for bug or security fixes and "extra" for non-iso packages built on the vanilla release (or built on the patches at most).

[caitlyn]

I like Joe1962's suggestion.  It seems like a good, balanced approach to the repos for future interesting upgrades that we might not want to be universal.

The advantages of a respin are two fold:

1.  For packagers and developers it gives us a new base from which to build.  Right now if I build on a "clean machine:" per VL standards and build against gtk+2 2.8.x there is no guarantee my package will work on a machine where patches have been applied.  If I build against gtk+2 2.10.11 my package will force an upgrade if installed with gslapt or slapt-get and may not work on a machine where patches have been applied.  By spinning a new release gtk+2 2.10.11 as well as the upgraded versions of cairo, glib2, pango, atk, etc... all become the standard that everyone works from.

2.  For users they get a tested and fully upgraded, GNOME-ready VL Standard built on the same 2.6.20 kernel as SOHO.  It saves hundreds of megabytes (or possibly over a gig now if you include a kernel upgrade) or downloads of patches if you choose to keep your machine up to date for security and bugfixes.

If it meant a lot of work for the developers I'd agree with waiting for VL 6.  The point is that other than testing the installer with new package bundles everything has already been developed and thoroughly tested.  This would only be an incremental release, not a new development cycle.

[The Headacher]

For packagers and developers it gives us a new base from which to build.  Right now if I build on a "clean machine:" per VL standards and build against gtk+2 2.8.x there is no guarantee my package will work on a machine where patches have been applied.  If I build against gtk+2 2.10.11 my package will force an upgrade if installed with gslapt or slapt-get and may not work on a machine where patches have been applied.  By spinning a new release gtk+2 2.10.11 as well as the upgraded versions of cairo, glib2, pango, atk, etc... all become the standard that everyone works from.

And break Slack 11 compatibility... the gtk package that comes with vl 5.8 is the default one from Slack 11. So if gtk 2.2.8 packages don't work properly on 2.2.10 it would be a release for which linuxpackages.net and slacky.eu are no longer useful package resources (at least for apps that use gtk).

I for one don't care much for a new version of VL 5.8 just because some package went to the wrong repo and now we're stuck with some weird packages we're not sure what to do with. The differences between the 2 versions aren't that huge IMO. If we're going to release a new standard with updated gtk etc. we'll also need to release a new SOHO, or just accept the fact that packages on "5.8.1 standard" will not work on "5.8 SOHO" without massive forced upgrading of packages. Or package on 5.8 standard after all so it will work on both most of the times.

Everything I've built on a clean 5.8 standard install has worked just dandy on SOHO (at least for me) . I honestly don't see much of a point in starting completely over with very little packages in the repo. We'll have to do that when VL 6 is released, which is one of the reasons I'm trying to learn SlackBuilds ATM. 

How's about nuking the offending packages (or at least moving them somewhere that isn't a repo that's enabled by default) to start with?

[easuter]

And break Slack 11 compatibility... the gtk package that comes with vl 5.8 is the default one from Slack 11. So if gtk 2.2.8 packages don't work properly on 2.2.10 it would be a release for which linuxpackages.net and slacky.eu are no longer useful package resources (at least for apps that use gtk).

But the GTK upgrade doesn't break GTK 2.8-based packages, Xfce and the rest continue to work after the upgrade (except for wifi-radar).
Anyway, I wouldn't have uploaded the packages if they were "destructive", its one of the reasons it took me so long to get GTK and GNOME finished: test packages, fix problems, test again, fix other problems, test again, fix, fix, fix, test, test, test, and so forth untill it worked... 

But yes, I do agree with sticking to "major" Slackware packages for official releases of VL.

So we have a few options, based on the discussion in the thread (but not limited to):

-nuke the packages
-create an "updates" repo
-create a gnome repo, where everything that gnome relies on, upgrade-wise, must be moved to along with the gnome core packages
-create a new release of VL with these packages as a base

Now its really up to the VL elders to make a decision regarding this

[Joe1962]

If we go the new repo route, I'd rather it isn't called "upgrades" or anything like that, because it sounds confusingly similar to "patches". I would prefer "experimental", or something in that vein. Even "contrib" if necessary...

[caitlyn]

To The Headacher:  It's not just Standard.  A slapt-get --upgrade will install gtk+2 2.10.11 into SOHO as well.  It's in both places.  The good news:  It's still only wifi-radar that gets broken.  Anyone going to move wifi-radar 1.9.8 out of testing so that a slapt-get --upgrade doesn't break anything?

[joec]

If we go the new repo route, I'd rather it isn't called "upgrades" or anything like that, because it sounds confusingly similar to "patches". I would prefer "experimental", or something in that vein. Even "contrib" if necessary...

From one of those new to linux, new to VL (not so good with Windows either) users -- confusion is bad. The two major issues i have faced are understanding partitioning and figuring out the repositories. VL seems to install with a large list of repositories, mirrors and potential repositories.
It is not always clear where to look for what. A repository for "patches" which only fixes security/bug problems without doing anything else is a good thing.