| 1 |
Fernando J. Pereda wrote: |
| 2 |
> Some of the packages I maintain are better removed when a new |
| 3 |
> maintenance version is released. And I plan to keep it that way :) |
| 4 |
> |
| 5 |
|
| 6 |
Can you clarify this? What scenarios do you run into where it isn't |
| 7 |
good for stable users to have access to more than one version of the |
| 8 |
software? |
| 9 |
|
| 10 |
One thing that I noticed is that in many cases there are multiple |
| 11 |
testing versions of a package available, and one stable version. So, if |
| 12 |
you run unstable you can pick and choose, but if you're running stable |
| 13 |
(which in theory should be the target audience gentoo aims for) then you |
| 14 |
get your choice of only one. |
| 15 |
|
| 16 |
I tend to think that unless something unusual is going on that old |
| 17 |
packages should be kept around for a while (a few weeks at least). The |
| 18 |
same should apply to packages in testing as well. Actually, that could |
| 19 |
be a whole separate topic. There have been many times that I've had to |
| 20 |
upgrade to a package in testing to get some needed feature, but then it |
| 21 |
gets deleted in favor of some other package in testing - and the stable |
| 22 |
package sits at its current version for ages. Unless a package in |
| 23 |
testing has a reasonably serious problem of some kind it would seem to |
| 24 |
make more sense to me to have ebuilds not removed until they've been |
| 25 |
stabilized and then obsoleted. An exception would be revision bumps - |
| 26 |
no sense stabilizing an ebuild revision that has a simple bugfix |
| 27 |
available without an upstream version change. |
| 28 |
|
| 29 |
Others have pointed out that inflexible rules aren't always the answer. |
| 30 |
I'd agree in general, but there should be guidelines. Maybe certain |
| 31 |
packages shouldn't have multiple stable versions to choose from. But |
| 32 |
when "certain packages" becomes 80% of them then I'd wonder if there |
| 33 |
really is a good reason for this... |
Archives