Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

Yes

No

[M0E-lnx]

Ever since the "Upgrade" feature was disabled in Vector Linux 5.9, I knew some people would ask "Why not?" ...
Most of us know the rule ... "If it ain't broke, dont fix it"... never the less, most of us do it anyway. So, here is something that I was thinking about.... And i'd like to see what everyone thinks about it too...

I was thinking we could release patchsets on a monthly or quarterly basis.
These patchsets would allow the users to safely install a predefined (and tested to work fine together) set of packages.

HOW WOULD THIS WORK?
It could basically be as simple as a metapackage.

With that in mind, please voice your opinion via this poll
Open for suggestions / comments / ideas.... Shoot!

[The Headacher]

Don't the problems with upgrades happen because everybody uses different programs? I could test something and say "it works fine for me", but that still is no guarantee it will work for others. it's exactly the same as providing upgraded packages IMO.

Perhaps though, we should rethink our policy of disabling the "update" button, and instead just make a warning pop up. Or, we could all try to upgrade more often and report errors when they occur. Apparently, people seem to think it's crazy to not upgrade your packages as soon as a new version of something becomes available. They may even be right. Perhaps, we should not make such a big deal of an occasional upgrade problem, and instead of saying "you shouldn't upgrade" say : "we're sorry the last package broke it, here's a new package that'll fix it."

Something else that may be worth looking into is the way our repo's are organized. People seem to find them confusing for some reason.

[nubcnubdo]

Not only am I not interested in upgrades, I appreciate not worrying about upgrades until the next VL comes out. If this isnt soon enough for compulsive upgraders, maybe we could cycle the version every six months, instead of once a year. A shorter cycle would be better (more competitive) from a publicity standpoint. When in Rome...

[newt]

I think the "release cycle" issue has basically been put to rest; it's not feasible at this point in time.  Many more devs, many more users, many more beta testers, etc... are needed.

I also think that competition with everyone else is not a high priority; being competative with OUR previous release IS .

Something about the meta-update packages doesn't seem like it's any better solution than the dist-update option.  Potential, crippling problems can still arise (perhaps less frequently, but still possible).  I'll think on this a bit more and post again (before I vote).

This has also been mentioned before (and I don't remember the conclusion), but perhaps an option to "undo" an update session could prove useful when a system gets knackered.  Basically something that tracks changes from 1 (maybe more) previous gslapt sessions and if the system is found to be knackered then that specific gslapt session could be undone (i.e. downgrade those packages that were upgraded/installed the previous session).  Of course, there are lots of issues with type of approach as well

[rbistolfi]

hmm, I dunno. we all will agree a full upgrade or any upgrade without a specific reason has no sense. I think was GrannyGeek who made a good argument about one should be able to do it under own risk. The Headacher has very good points as well. Anyway, looks like people feels insecure without the upgrade, and a patchset could give an image of security.
What I would like to see is some packages to fix known issues. Could work in this way: we find a bug which filtered into Gold. We find the fix. Instead of wait for each user to find it and repeat the solution in the forum, we could script the solution and release it as a package. Examples of this case would be the slapt-getrc file in 5.8, or the firewall thing also in 5.8, and such. I think we don't have any yet in 5.9, perhaps a recent gmplayer issue. Fixes should go to the Patches repo, which should be always enabled by default and people should install packages from there always.
upgrade after install. I never upgraded more than a few packages and I never had a security problem since using VL.
Just some ideas.

[nubcnubdo]

What I would like to see is some packages to fix known issues. Could work in this way: we find a bug which filtered into Gold. We find the fix. Instead of wait for each user to find it and repeat the solution in the forum, we could script the solution and release it as a package. Examples of this case would be the slapt-getrc file in 5.8, or the firewall thing also in 5.8, and such. I think we don't have any yet in 5.9, perhaps a recent gmplayer issue. Fixes should go to the Patches repo, which should be always enabled by default and people should install packages from there always.

I can go with this, if we aren't doing it already. Good idea, rbistolfi.

[tomh38]

What rbistolfi and nubcnubdo
said, good idea it is, hmmmm?

[easuter]

Why did we even bother disabling the "Upgrade" button in Gslapt then?

[Sivatheja]

Something else that may be worth looking into is the way our repo's are organized. People seem to find them confusing for some reason.

Yes, I'm brand new to vector, and the number of packages available for download with (only) two sources was overwhelming, and enabling all and then choosing is alien!

It was really laborious to read whole description in GSlapt package manager just to know that the package is not useful for me. It would be nice if the packages are organized like 'development' 'games' 'applications' etc.

I even have a suggestion, application names may not be self explanatory, (like XMMS). So a search with 'players' should give  XMMS as search result. What I want to say is, end user need not know the correct application name to install it, a smart search should make the job easy.

[The Headacher]

enabling all and then choosing is alien!

you shouldn't enable all. Look at the last directory name, you shouldn't have more than one with the same name enabled, e.g. just one ending with /packages/, one with /patches/, etcetera. If you enable more of them, it's just going to take longer to update the package info.

So a search with 'players' should give  XMMS as search result. What I want to say is, end user need not know the correct application name to install it, a smart search should make the job easy.

Perhaps we should try to put keywords in the package description. But I don't think gslapt/slapt-get supports using package categories. slapt-get is developed for Slackware, and I don't think slackware packages support categories, but I may be wrong. Anyways, I don't think searching by category will become a reality any time soon. But if you search gslapt for "player", xmms is already one of the results.

smart searching is as much a responsibility of the user as it is of gslapt.

[Sivatheja]

enabling all and then choosing is alien!

you shouldn't enable all. Look at the last directory name, you shouldn't have more than one with the same name enabled, e.g. just one ending with /packages/, one with /patches/, etcetera. If you enable more of them, it's just going to take longer to update the package info.

Oh! I didnt know that!

So a search with 'players' should give  XMMS as search result. What I want to say is, end user need not know the correct application name to install it, a smart search should make the job easy.

Perhaps we should try to put keywords in the package description. But I don't think gslapt/slapt-get supports using package categories. slapt-get is developed for Slackware, and I don't think slackware packages support categories, but I may be wrong. Anyways, I don't think searching by category will become a reality any time soon. But if you search gslapt for "player", xmms is already one of the results.

smart searching is as much a responsibility of the user as it is of gslapt.

'XMMS' was just for an example; but with this much of response I think we dont require search

[caitlyn]

Patchsets for known security vulnerabilities are a very good idea.  So are bugfixes. 

Including a newer version just because it has some new gee whiz feature or because it happens to be available falls into the "if it ain't broke..." category.  Sure, make newer packages available in the repos and if someone wants to do a system-wide upgrade let them. 

So, my response is a resounding "yes" to patchsets but only include patches that actually fix something that is known to be broken.

[GrannyGeek]

I'd like Gslapt to work the way it did in 5.8. Let me do a Mark Upgrades and then Display Marked. I'm NOT going to install them all. In fact, usually I don't install any. But I like to see what upgrades are available and then if they are programs I use, I can decide whether or not I want to upgrade.  I really don't like having that option disabled. It seems nannyish to me. Yes--include a warning about upgrading at your own risk because things may break. But don't make it extremely difficult for me to see what upgrades are available without going through a laborious and time-consuming search through the whole list.

As I understand it, the patches repository is for security and bug fixes. Testing is for packages not yet officially released and they have more of an element of risk to them.

I prefer the 5.8 way rather than a patchset. A patchset isn't necessary with the 5.8 way. I understand the motive behind disabling the Mark Upgrade and Show Marked options, but I don't agree with it. I don't think Linux users need to be protected from themselves if a warning is given.
--GrannyGeek

[The Headacher]

I prefer the 5.8 way rather than a patchset. A patchset isn't necessary with the 5.8 way.

Agreed. Making patches seems like an overcomplicated way to get around a problem (users get in trouble when they "slapt-get --upgrade") rather than solving the actual problem (crappy packages).