Re: [gentoo-dev] Keeping older versions around
On 21:33 Sat 28 Jan , Ryan Hill wrote:
I've run into this three times today, so I'm a little grumpy. When you bump
to a new ~arch version, please consider keeping at least one previous ~arch
version around, so if people run into major issues they can at lease try the
previously installed version to determine if it's your package at fault.
Recent version bumps to two libraries have completely trashed a package I
maintain, and the only option for my users is downgrading them to stable,
which requires downgrading several other libraries. In both cases, the
previous ~arch version, which worked fine, was removed.
Personally I always try to keep two versions in ~arch and one stable,
excepting security or other major bugs that render an older version useless.
Agreed with a slight modification — once you've kept the old
{stable,~arch} version around for a reasonable amount of time (say 30
days), you should be safe pulling it.
--
Thanks,
Donnie
Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com
Analyst, RedMonk http://redmonk.com/dberkholz/
pgpSKypfDxmlZ.pgp
Description: PGP signature
Re: [gentoo-dev] Keeping older versions around
Donnie Berkholz dberkh...@gentoo.org writes:
Agreed with a slight modification — once you've kept the old
{stable,~arch} version around for a reasonable amount of time (say 30
days), you should be safe pulling it.
As long as there are no open bugs on the later ~arch version breaking
other packages.
Re: [gentoo-dev] Keeping older versions around
On 1/30/12 6:17 AM, Donnie Berkholz wrote:
Agreed with a slight modification — once you've kept the old
{stable,~arch} version around for a reasonable amount of time (say 30
days), you should be safe pulling it.
Agreed with a slight modification ;-)
Please make sure that at _any_ given moment you have an ~arch ebuild
that has spent 30 days in ~arch (unless it's already stabilized).
If you remove such an ebuild after 30 days without stabilizing it, you
can still create a situation where no ebuild can be stabilized because
the existing ~arch ebuilds are too recent.
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Keeping older versions around
I've run into this three times today, so I'm a little grumpy. When you bump to a new ~arch version, please consider keeping at least one previous ~arch version around, so if people run into major issues they can at lease try the previously installed version to determine if it's your package at fault. Recent version bumps to two libraries have completely trashed a package I maintain, and the only option for my users is downgrading them to stable, which requires downgrading several other libraries. In both cases, the previous ~arch version, which worked fine, was removed. Personally I always try to keep two versions in ~arch and one stable, excepting security or other major bugs that render an older version useless. -- fonts, gcc-porting toolchain, wxwidgets @ gentoo.org signature.asc Description: PGP signature
Re: [gentoo-dev] Keeping older versions around
On Sat, Jan 28, 2012 at 10:33 PM, Ryan Hill dirtye...@gentoo.org wrote: When you bump to a new ~arch version, please consider keeping at least one previous ~arch version around, so if people run into major issues they can at lease try the previously installed version to determine if it's your package at fault. I mostly run stable and when I have to pull in the odd ~arch package it seems like for some of them I'm re-keywording them every third day. The stable version doesn't change in 9 months, and the unstable one changes 47 times, with old versions being dropped instantly so I have no choice but to move along or risk having a security bug that won't get GLSA'ed. Also, if we don't keep unstable versions around there isn't any way to get them stabilized, making stable more stale. If a particular unstable version is particularly buggy or otherwise not something upstream supports then it makes sense to move on. However, everything has some level of bugs (if you look hard enough) and if they're pretty minor then we should be asking ourselves if it is better or worse than the current stable, and if not then it should be left around if possible as a stable candidate. Obviously use common sense. If we can afford our users the luxury of upgrading at their leisure we should do so. Rich
