I suggest a new /etc/make.conf FEATURE like "failback" which will build a binary package just prior to unmerging a package. I'm well aware of the FEATURE buildpkg, but actually I don't always want those binary packages laying around and am sometimes forced to clean $PKGDIR (and sometimes it was not activated at all emerging the old package). Using the suggested feature would allow not to care about binary packages at all but would guarantee that if we update we would have a failback package, namely the one which was working just beforehand. The provided patch (for sys-apps/portage-2.1.1-r2) just calls quickpkg before unmerging the package. This is how I'm using it at the moment.
Created attachment 102740 [details, diff] Applying this patch portage will create a binary package of the package which is about to be removed.
(In reply to comment #0) > I suggest a new /etc/make.conf FEATURE like "failback" which will build a > binary package just prior to unmerging a package. > > I'm well aware of the FEATURE buildpkg, but actually I don't always want those > binary packages laying around and am sometimes forced to clean $PKGDIR (and You can use eclean from app-portage/gentoolkit to clean unwanted binary packages. > sometimes it was not activated at all emerging the old package). Using the > suggested feature would allow not to care about binary packages at all but > would guarantee that if we update we would have a failback package, namely the > one which was working just beforehand. > > The provided patch (for sys-apps/portage-2.1.1-r2) just calls quickpkg before > unmerging the package. This is how I'm using it at the moment. Sure, it's useful if you haven't had buildpkg enabled, but I think you should just enable buildpkg and use eclean regularly.
buildpkg has one disadvantage (or is it an advantage?) to the proposed solution: It will store the vanilla config files instead of the ones in $ROOT. Not a big deal but could be useful in some cases.
Exactly. That's the main reason I'm using it. At first glance it may seem like an overlapping feature - but I call it an enhancement since it does the same thing differently resulting in a (most likely) different binary. I still think the resulting binary is what most people would like - especially when you upgrade and things fail. There's no easier failback than to have a binary which exactly represents the last state (including config files).
*** Bug 78383 has been marked as a duplicate of this bug. ***
*** Bug 88997 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 54113 ***
I don't agree that this bug is a duplicate of http://bugs.gentoo.org/show_bug.cgi?id=54113 . # emerge --depclean can be a dangerous command if you don't know what you're doing (well, what isn't) and has a 13 line warning header, meaning EVERYONE will stop a depclean if he doesn't know what he's doing. On th other hand my suggestion doesn't try to protect a user from it's own ignorance. But a user relies on the decision the developer teams make and when portage wants to update packages he'll usually follow the suggestion blindly. The solution (which at the moment is more like a pointer) will diminish frustration from update failures and certainly take heat away from developer teams or gentoo generally. Wouldn't it be the easiest/most elegant solution to tell the user: don't worry, every time you make an update of a package the prior package will be saved (including the configs) and in case of a problem you may quickly do a rollback - EVEN if you updated/merged your old /etc/* files (which we STRONGLY suggest anyway). I (still) suggest a (in my opinion default) FEATURES option called something like failback - which will quickpkg the package that is just about to be updated. I'm inclined to reopen this bug ... but will wait for further input.
I agree, the other way around would be more appropriate.
*** Bug 54113 has been marked as a duplicate of this bug. ***
*** Bug 127797 has been marked as a duplicate of this bug. ***
*** Bug 183283 has been marked as a duplicate of this bug. ***
*** Bug 321091 has been marked as a duplicate of this bug. ***
Consider advices in Bug 321091
That patch...it does not implement that upgrade feature as in Bug 321091 right?
Name it FEATURE=unmerge-backup please; I added support for this to pkgcore in april of '08, I'd rather not have an incompatibility in portage configuration introduced when portage grows equivalent functionality...
This is fixed in git: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=f807bb54317db5f8073f8904897cf4b9d87bf2cd
This is fixed in 2.1.11.4 and 2.2.0_alpha115.
WOW! Thanks!!
