There're many packages that a user doesn't want always, thus it makes sense to unmerge it. Problem with a source based disto is, remerging the package when its required is a bad idea... so the user will ideally prefer keeping that package installed. But we can build binary package (for e.g. named A) off it, that's a quick way to reinstall that package when required, but what about the dependencies? That will resolve with bug 320577, but what if you unmerged another package (B) and then did a depclean to realize that A required it, then if package A is required package B will have to be merged separately increasing the time taken. To solve this issue, portage should get a feature called 'virtual installation', where portage will assume as if package A has been installed but actually it will not be installed what portage will do is keep a watch on the virtually installed package's dependencies and if they are ever unmerged, it will build a binary package and then unmerge it. Another feature of this 'virtual installation' should be updates. If the package or any of it's dependencies are upgraded, portage will make a binary off that updated package and then unmerge it, thus maintaining the binary without user intervention and it can be installed quickly with --getbinpkgonly. Reproducible: Always Steps to Reproduce:
And maybe this feature will be very useful --with-bdeps=n. May be this virtual installation will have a feature to maintain the binaries of the build time dependencies. Hard feature to implement.
(In reply to comment #1) > Hard feature to implement. > Yeah, I don't think this is going anywhere. If you want to be on the save side, create binaries for everything with FEATURES="buildpkg". That's more or less what happens if you create them on update. The only difference is at which point the binary gets created. At build time is better btw, because of configuration file changes. If you need to create binaries later on you can still use quickpkg. You could even let it run on every unmerge (updates involve an unmerge too) by playing with /etc/portage/bashrc.
(In reply to comment #2) > (In reply to comment #1) > > > Hard feature to implement. > > > > Yeah, I don't think this is going anywhere. If you want to be on the save side, > create binaries for everything with FEATURES="buildpkg". That's more or less > what happens if you create them on update. The only difference is at which > point the binary gets created. At build time is better btw, because of > configuration file changes. If you need to create binaries later on you can > still use quickpkg. You could even let it run on every unmerge (updates involve > an unmerge too) by playing with /etc/portage/bashrc. > That's just going to blindly create binary, with this - 1) You have to manually maintain the binaries by recording the packages for which you made the binaries and update them every time you update since you would have unmerged the package (for which you want the binaries)... so the binaries wont be made even during an update simply cause the package will not be installed. 2) If you unmerge, each and every package will be made a binary creating a huge repository of binaries... which is not desired. Here Only a select few will be monitored. 3) The above is true in general... who will delete the tree of binaries? Who knows what's important what's not? 4) I got a feeling you did not understand anything of the 'virtual installation' concept.
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > > > Hard feature to implement. > > > > > > > Yeah, I don't think this is going anywhere. If you want to be on the save side, > > create binaries for everything with FEATURES="buildpkg". That's more or less > > what happens if you create them on update. The only difference is at which > > point the binary gets created. At build time is better btw, because of > > configuration file changes. If you need to create binaries later on you can > > still use quickpkg. You could even let it run on every unmerge (updates involve > > an unmerge too) by playing with /etc/portage/bashrc. A better notion is to add FEATURES=unmerge-backup; thought portage grew something similar at somepoint... > 4) I got a feeling you did not understand anything of the 'virtual > installation' concept. Clarify it better than. I suspect folk do get it, just disagree on the feasability of your request. You essentially want all DEPENDS from vdb collapsed, differenced from what is actually installed in vdb, and that subset backed up to a caching binpkg repo on unmerge (whether depclean or unmerge, same end result). Caveat there is that anytime the installed graph changes, you want it to cleanup the caching binpkg repo... which is annoying to say the least. It also has a core usability flaw- under your scheme, say all the depends of mutt are stashed in that caching binpkg repo, and their refcount is 1 (meaning they're kept alive only for mutt). For whatever reason, I want to do a temp unmerge of mutt, then remerge it. In doing so, refcounts go zero, the caching binpkg repo gets cleansed, I go to remerge mutt and I get to rebuild all of the deps. Whee. Offhand, you're likely to get better traction via a combination of FEATURES=unmerge-backup (potentially w/ a commandline option to disable it, or some form of white/blacklisting) and getting whatever binpkg repo cleaner you use to know about the installed pkg graph (and probably maintaining an expiry- wait a month or so before permanently deleting the pkg for example). Also, generating the binpkg at build time (prior to merging, where it gets modified by QA, by whatever feature-of-the-week you're playing with, let alone install_mask of the week) *is* the best time to generate these binpkgs. Just because quickpkg exists doesn't mean it generates the best results.
"Caveat there is that anytime the installed graph changes, you want it to cleanup the caching binpkg repo..." Yeah, that's the feature, potage has to do the maintenance automatically, as if the packages are 'virtually installed'. "For whatever reason, I want to do a temp unmerge of mutt, then remerge it." If you want to keep this package installed always, there's no use installing it virtually. The utility of this is to unmerge the package that you might not need frequently and in case you need it someday, you can safely install it using --getbinpkg since portage will be maintaining the binaries always. If you realize that you'll be needing it frequently you'll remove it from the virtually installed package list. "the caching binpkg repo gets cleansed" No, the model is unless and until the package is installed as a virtual package, it will be maintained even if you merge or unmerge it. "Also, generating the binpkg at build time (prior to merging, where it gets modified by QA, by whatever feature-of-the-week you're playing with, let alone install_mask of the week) *is* the best time to generate these binpkgs. Just because quickpkg exists doesn't mean it generates the best results." The binaries are going to *maintain* during build time. quickpkg will be used though... think. Ok, let's explain this thing again. Suppose, you have k3b installed on an xfce desktop, which's the only thing pulling heavy dependencies and you require k3b in like... once in 2 or 3 months, so what can you do with this package is to record it in the virtually installed list and then unmerge it; on doing so, portage will build a binary package off k3b; then you decide to do --depclean, this will remove the k3b dependencies but cause k3b is virtually installed, before an unmerge of the dependencies portage will build it's binaries. Similarly if one of a dependency is in the world favorite file, unmerging this will also build a bin package cause k3b is installed as a virtual package.Point is, when I again decide to reinstall k3b, everything will be done from binaries. Now, what's the difference between blindly making binary packages of all packages that are being unmerged and making binary packages of the dependencies of the package that are installed in the 'virtual' list? Difference is, even if you unmerge the complete xfce desktop the whole xfce desktop will be made a binary package if you have buildpkg as a feature (or something similar), but with virtual packages, only the once which are the dependencies of k3b will be made a binary... only the relevant packages which are required to install k3b completely from binary. Now, what if you merge k3b again and then unmerge it? The binaries will not be removed or rebuild this way... they will remain as it is, but if you install another package which pulls in K3b's dependency or dependencies or even if one (or more) of the dependency is recorded as in world favorite, then the binary package will be remove, not if only k3b is installed (which's in the virtually installed list) and if this is the only one pulling in the dependencies. Generally speaking the bins will be deleted only if - 1) Some packages are removed from the virtually installed list 2) A dependency is recorded as the world favorite 3) Another package which's not in the virtually installed list is merged and it pulls in the dependencies of one (or more) of the package which are listed in the virtually installed list.
Offhand, drop the 'virtual pkg' and/or 'virtually installed'. The phrasing there doesn't translate exactly well and confuses existing virtuals (which can be real pkgs, or provide based 'virtually installed' pkgs) into the mix. What you're asking for is far easier to sum up as the following three requests: 1) FEATURES=unmerge-backup 2) addition to unmerge-backup w/ a whitelist that cascades down through the subgraph of the targets deps/rdeps 3) repository ordering preferance per pkg for preferring binpkgs (where possible) over source based on a whitelist (same whitelist for feature #1)
So all this is available currently in portage? If so how do I do it, how do I make a white list?
(In reply to comment #7) > So all this is available currently in portage? > > If so how do I do it, how do I make a white list? I broke down the 3 features you're _requesting_; they need implementing. unmerge-backup shouldn't be particularly hard... others, not so much. @sebastian- note the trigger design for MergeEngine in my code is something you might to look at for features of this sort.
Ok, you seem to have understood what I mean. So not something very hard after all.
