The bad news: That gtk+ upgrade placed in patches to allow for the latest and greatest GNOME. That's an upgrade no other distro would have dared do -- a major upgrade of gtk without spinning a new release of the distro.

No. headacher raised a valid point. Either gtk+2 2.10.11 should have immediately become our new standard (i.e.: everything built against it) or it should never have gone into patches. I argued against the gtk+ upgrade, if you remember. Now you know why. What has been done is contrary to the practices of every major distro for a reason. You can't have two standards at once in the same version of the distro.

I argued agaisnt this too. I also wasn't happy with all the upgrading that took place between 5.8 Standard and SOHO, as it makes common packages and repo all the more complicated. I proposed a common base during the pre-development phase of Dynamite 5.9, which was to become 6.0, but actually became 5.8. I hope this common base can really be achieved in 6.0, as it did not work out for 5.8.

My solution, which I'm fairly sure will be rejected, would be to take the current state of VL 5.8, gtk+ 2.10.11 and all, since it does all work and is now well tested, and respin as Vector Linux Standard 5.8.1. Kind of like Mandriva 2007.01 (Spring), it isn't a major new release but it does set a new base to work from with lots of cool upgrades.

FWIW, I support this proposal.

« Last Edit: June 22, 2007, 02:12:43 pm by Joe1962 »

Logged

O'Neill (RE the Asgard): "Usually they ask nicely before they ignore us and do what they damn well please."http://joe1962.bigbox.infoRunning: VL 7 Std 64 + self-cooked XFCE-4.10

The bad news: That gtk+ upgrade placed in patches to allow for the latest and greatest GNOME. That's an upgrade no other distro would have dared do -- a major upgrade of gtk without spinning a new release of the distro.

[...]

Either gtk+2 2.10.11 should have immediately become our new standard (i.e.: everything built against it) or it should never have gone into patches. I argued against the gtk+ upgrade, if you remember. Now you know why. What has been done is contrary to the practices of every major distro for a reason. You can't have two standards at once in the same version of the distro.

Its a bit of a double edged blade...

Both are very valid points though. There were no plans at all for a "home-brew" GNOME when VL 5.8 Standard was being developed so no "rule" was set for what would happen to the package upgrades needed by GNOME.

However, when GNOME and its deps were added to the repo, SOHO hadn't even been released yet (it was still RC1 or RC2), and neither had the LiveCDs IIRC. Still a lot of work was being done on those projects. So to be able to use GNOME at all, we would have had to wait until these were finally finished to be able to make (and test) a VL 5.8.1 Standard that included the GTK and all the other upgrades...?

It would have made perfect sense to do that, but unfortunately manpower is not one on VL's strong points...

Hopefully a clear (and publicly accessible) roadmap can be drawn up for VL6, which addresses issues like as to how far packagers can go before a new VL release is required, with all the "do's and don't-do's". However, Slackware 12 will also be a major "leap into the present", with lots up-do-date packages in the default installation, so this will reduce (maybe almost eliminate) the need for such prolific package upgrades that we've seen for VL 5.8.

EDIT: better direct communication between packagers/devs/etc would be nice too...

joe1962: Your solution to getting this issue discussed is perfectly fine with me if the core developers and decision makers are here.

FWIW, I agree with everything said by joe1962 and eauster so far. I'd like to bring a couple of additional points from the previous thread which I made to this one to hopefully focus on why this discussion is important:

Quote

A lot of places (particularly businesses and government) as well as security paranoid individuals like me want to keep any known vulnerabilities closed. I do this stuff for a living, though not with Vector Linux. I'd love VL to get to the point where businesses and government think it's worth considering. You may have no idea how close, quality wise, this distro is.

You've just raised another point. gtk+ 2.8.x wasn't a security vulnerability and it wasn't broken. There wasn't a compelling reason other than GNOME 2.18.0 to put gtk+ 2.10.11 in patches. It, with GNOME, probably needed to be put in a separate (new) repository so that everyone who does a

slapt-get --updateslapt-get --upgrade

wouldn't get it. It's too late for that now.

The point I'm making is that we need to have a sensible upgrade policy and a build policy that tracks it. This isn't about individual choices but rather what our user community, especially people migrating from things like the very broken recent release of Xubuntu Feisty Fawn, is likely to expect from us.

When Daniel Baranger of Red Hat suggested that VL lacked karma (he couldn't find another way to say why he didn't like it) I kind of agreed. I think this is an example of why. It isn't that there is anything wrong with VL. It's actually pretty darned impressive at this point. It's more suffering growing pains and needs some more rigorous (professional?) standards that we all follow. Oh, and yeah, that includes me even if I don't like them -- hence my feeling that I need to build against a clean box since that is the current standard -- at least until this issue is addressed.

In every other major distro (I'm assuming VL is moving into the ranks of majors here) once something is in patches or the distro equivalent it is the de facto standard. Every other major distro recommends keeping up with patches. Up until VL 5.8 there was no workable mechanism to do that. With VL 5.1 the docs advised against a slack-get --upgrade for good reasons:

If you tried to do a mass upgrade on 5.1 you broke things. On 5.8 that is no longer true. It works like a charm, even with the rather daring gtk+ 2.10.11 upgrade. The sole broken piece after the gtk+ upgrade is wifi-radar and the package which fixes that is in testing. Doing a mass upgrade is what someone migrating from another distro with sane package management (read: NOT Slackware) is probably used to and it's what they likely expect.

The nice thing about respinning the current iso is that you basically replace the stuff on the current iso with the stuff from patches (plus wifi-radar 1.9.8 from testing) and go with what you have. It's pretty much all tested already except for running the installer with the newer packages. Considering the huge amount of stuff already upgraded (xfce, seamonkey, firefox, gtk+, glib2, vl-hot, cairo, pango, etc...) I don't think it would be much a stretch to "release" 5.8.1 as it has as many or more changes than what typically happens between two releases of Ubuntu or Fedora or whatever. You wouldn't need new repositories either... just continue with the existing ones. You also get the bonus of new community press on the new "release".

Re: SOHO. My forthcoming review for O'Reilly makes the point that it should have been called 5.8.1. It has so many changes and upgrades from Standard that they can't really be considered the same version IMHO. BTW, you're going to like my review of SOHO. I haven't seen KDE move that fast on my aging hardware in ages.

So the question becomes, if somebody builds a new version of a package that comes with VL and is likely to give compatibility issues (not a bugfix or security update ), where DO we put it (we already established it shouldn't go into patches)? Unstable?

if somebody builds a new version of a package that comes with VL and is likely to give compatibility issues (not a bugfix or security update ), where DO we put it (we already established it shouldn't go into patches)Huh? Unstable?

I think there also has to be a destiction in future of whether the package is a "major" upgrade. If its something trivial its probably not a problem to be added to the patches repo...or maybe there should be an "updates/" directory to destinguish the non-critical package upgrades from the critical ones?...

A lot of places (particularly businesses and government) as well as security paranoid individuals like me want to keep any known vulnerabilities closed. I do this stuff for a living, though not with Vector Linux.

There are businesses that are looking at Vector. As far as security and stability, Vector is decent. There are too many services offered on a stock install. The firewall decision is good but has been mind boggling to many who are trying the get networking running. Then they find out through several hours of testing that a firewall is in place. A note on the install would be nice.

Quote

Up until VL 5.8 there was no workable mechanism to do that. With VL 5.1 the docs advised against a slack-get --upgrade for good reasons:

The repository is not there still IMHO. In order to handle that type of request a sane base needs to be developed and adhered to. Then scripts to evaluate all packages and then upgrade. Mass upgrades are happening in other distributions. However other than reading the whole changelog how does a person know what happened to there system? Both of the above require manpower that may not be available at present.

The GTK issue should have not become an issue. In order to preserve sanity only form of GTK should have been used. As noted too many chances of things going wrong.

Why is it that everytime that a new update (not a patch) comes down the road that it has to be included? IMHO sticking to a base for standard and SOHO keeps stability. A patch repository isa good idea.

Slackware is a stable platform without any suprises. Vanilla everything, no tweaking. Slackware current is moving toward a desktop vs a server. The less tweaking the better the ability of users to keep up with there system if they so choose.

The GUI vs Text installer why is that? Most others do it so we have to? Lets stick to what Vector is straightforward and clean. During an install how about all on board hardware runs that is possible, in the end users will love you for it.

Now, now. Considering the nature of this thread, not to mention the problems being experienced by Red Hat, Ubuntu, et alia WRT improper handling of dependencies and maintenance of repositories, are you sure this is not a case of the lunatics running the asylum?

Logged

A complex system that works is invariably found to have evolved from a simple system that works.

I haven't experienced any serious problems with Ubuntu. Fedora Core has had serious problems, not Red Hat Enterprise Linux. In any case, all the majors generally do have sane package management. Lately so does Vector Linux. Slackware still doesn't handle dependencies so it doesn't.

I am not sure what your definition of "serious problems" is, but for me it means a package manager demands more of my time working around other people's screwups than I do handling my own.

Try performing an 'apt-build world --recompile' with Ubuntu and tell me the packages are being managed properly; even Ubuntu's developers recommend against performing version upgrades.

RPM still can't handle the order in which packages are required to meet dependencies. Maybe the RHEL repositories have this sussed, but for a $300 a year subscription, I should expect some accountability. FWIW, I have seen recent discussions about PostGreSQL dependency problems with RH and, as you stated, FC seems to be something of a mess.

There is nothing "insane" about trusting one's own abilities to maintain his system over those claimed by someone else, especially when those claiming to be able to handle the task have a ten-year track record of failure. One of the reasons Slackware is so reliable is because its developers are able to focus on fixing the problems in the packages, not the ones in the package manager.

Logged

A complex system that works is invariably found to have evolved from a simple system that works.

RPM still can't handle the order in which packages are required to meet dependencies.

This hasn't been true for years, as in since rpm 4.x.

10 year track record of failure? SuSe, Mandriva, Fedora up to FC4, Red Hat, Ubuntu, and Debian all have done a good job -- to the point where most users will never notice a problem. Slackware is *known* for dependency hell because it doesn't even try to handle dependencies at all. It's why I wrote off Slackware as a geek toy years ago.

The reason VL is getting so much attention is because it has successfully matched Slackware stability, reliability, and speed with the ease of use, most especially including package management, that the major distros are known for.

Now, let's get back to solving the very real issues rather than attacking other distros which are far more popular than either Slack or VL -- and for good reason.

Now, let's get back to solving the very real issues rather than attacking other distros which are far more popular than either Slack or VL -- and for good reason.

Indeed... Let's get back to discussing how to make our repository better. You can always find someone worse than yourself and use this as justification, but I find the best way is to constantly strive for perfection, only then will you get as close as humanly possible to it...

« Last Edit: June 25, 2007, 08:00:36 am by Joe1962 »

Logged

O'Neill (RE the Asgard): "Usually they ask nicely before they ignore us and do what they damn well please."http://joe1962.bigbox.infoRunning: VL 7 Std 64 + self-cooked XFCE-4.10

10 year track record of failure? SuSe, Mandriva, Fedora up to FC4, Red Hat, Ubuntu, and Debian all have done a good job -- to the point where most users will never notice a problem. Slackware is *known* for dependency hell because it doesn't even try to handle dependencies at all. It's why I wrote off Slackware as a geek toy years ago.

Slackware is in no way "known" for dependency hell (try googling "slackware dependency hell" and see what comes up). The reason Slackware doesn't have a dependency hell is because they don't split every program up into a half dozen different packages. If you have the packages from the first two installation disks, 99% of your system needs are met. Ever hear of the Pareto Principle? If you actually examine your entire process of system maintenance, you will find that the complexity of the RPM and APT systems creates more problems than it solves. Vector developers would be well-served to keep the big picture in view while improving their own system of package management.

Logged

A complex system that works is invariably found to have evolved from a simple system that works.

Perhaps I'll continue the discussion (argument?) with Saul in another thread. It's gotten us way off topic. No disrespect to Saul intended, but...

Right now the issues are:

1- Is doing a major upgrade of core libraries with a release cycle (i.e.: gtk+2, glib2) was a good idea or not?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 and3- 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

There seems to be support for a separate repository other than patches (I agree with this, BTW) and for a respin, which I originally proposed.

I'd like to hear from the movers and shakers, the people who actually make such decisions.

1. It was a bad idea, and IIRC was warned against by a few different people.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.3. IMO Yes, but ultimately that will be vecs decision.