Hi, I've added a small feature to my portage to keep binary packages tarballs of system packages. I thought this may be usefull in case I break glibc/gcc/python/portage/whatever. The FEATURE flag is named "buildsyspkg", and implementation is local to "bin/emerge", class "depgraph", method "merge". I will attach a patch, made against 2.0.49-r16. It won't apply to -r18, sorry. I will post an updated patch later, but have not moved to -r18 yet. Also, I would like to hear your opinion on a more general approach to selecting what binary packages one want to keep. Here is what I have in mind: - only feature "buildpkg" force tarballs creation - a variable "PACKAGES_TO_KEEP" defines what are packages that should be built when "buildpkg" is enabled. It's default value is "*", so that "buildpkg" default behavior doesn't change. - in this variable, you can set both some "category/package" entries, or/and the usual packages sets ("system" and "world") The goal is to be able to define a real backup policy for packages. Personnaly, I want to: - keep system packages for safety - keep xfree/open-office/mozilla because they are slow to build and I sometimes use them on other stations, or share them with other people - drop all other packages I'm sure I'm not the only user with this kind of policy, more or less applied by hand now. Any suggestion/criticism before I start implementing this? Thanks.
Created attachment 21634 [details, diff] 2.0.49-r16-buildsyspkg.patch
Created attachment 21963 [details, diff] 2.0.49-r18-buildsyspkg-feature.patch Here is the same patch against -r18.
I realized there is a bug: when a package instanciates a virtual from system, it is not recognized as being part of system. For instance, no binary package will be created for modutils, because it is virtual/modutils that is in system. I've start working on the more customizable solution I've described in my first post, so I think I will only fix this there.
I've more or less implemented the other patch I've described in comment #1. With this version, there is no more "buildsyspkg" feature flag, but the behavior of "buildpkg" changes. Binary tarballs are now built depending on a policy defined by the incremental variable BUILD_PKGS. Valid rules are {*,system,category,category/package}, and their negations ("!something"). A package will be kept if it matches at least one positive rules, and no negative rule. The default should be "*" so that "buildpkg" default behavior doesn't change. Example to keep all packages but kernels/headers: BUILD_PKGS="!sys-kernel" Example to keep system packages but kernels/headers, and also xfree: BUILD_PKGS="-* system !sys-kernel x11-base/xfree" Misc notes: - "world" is not a valid rule. This is because when I check if a package is to be kept, it is probably not yet in world file. But I don't really think this rule would have been useful. - "system" is still problematic because of virtuals (see my previous comment). What I've implemented solve most of the cases, but will still fail to recognize a package that provides a system virtual if it is merged for the first time and is not the virtual default. This is because the package is neither yet in profile/virtuals, nor in edb/virtuals. A really correct implementation can only rely on the "PROVIDE" field of the ebuild, but I can't use it because it is not an aux_get key.
Created attachment 22080 [details, diff] custom-buildpkg-2.0.50_pre1.patch The patch includes a reverse for the previous "buildsyspkg" stuff.
Created attachment 22081 [details, diff] custom-buildpkg-cnf-2.0.50_pre1.patch This is a proposal of some make.{globals,conf} additions.
looking at the code I think it handles "!foo foo/bar" wrong as it breaks the for loop in isbuildpkg() on the first matching negative rule, so it won't build a package for foo/bar. And somehow I'm not comfortable with the syntax for BUILD_PKGS either, just thinking about a better way.
It's not a bug, it's a feature :/ The predicate is "at least one positive rule and no negative rule". This was enough for the few policies I've thought of, but it is true that for your example it is stupid. A better predicate would be "at least one positive rule with no negative rule of a lower level", meaning that for instance: - "system !category" (resp. "system !cat/pkg") would build for system but the category (resp. the pkg), because a category rule (resp. a pkg rule) is lower level than the system rule. - "category !category/pkgA" would build the whole category but pkgA, because a pkg rule is lower level than a category rule. - "system !category category/pkgA" (your example) would act as expected ({system} - {category} + {category/pkgA}), because the last rule is positive and no lower level rule negates it. Would it be okay like this? I will code this soon to make it clear. On the syntax, well, I agree it is not quite intuitive. I'm opened to any better proposition. The only thing that really limit possibilities I think is that I would like to keep the var incremental, so that you can easily add a package to your build list on command line before a "emerge -uD world" for instance.
Created attachment 23379 [details, diff] custom-buildpkg-2.0.50_pre10.patch Here is a patch modified as described in the above comment, that should better handle Marius' example.
Created attachment 23380 [details, diff] custom-buildpkg-2.0.50_pre10.patch Doh!, did I really do that? Sorry, this one sounds better.
Created attachment 23666 [details, diff] custom-buildpkg--code.patch Updated for 2.0.50_pre12.
Created attachment 23673 [details, diff] custom-buildpkg--conf.patch Updated make.conf comments.
Created attachment 24890 [details, diff] custom-buildpkg--code.patch Seems that when i've attached the last update, i've choosed the wrong file, and reverted the rules priorities stuff introduced in the previous version. Here is the right, finally, the right patch.
supposed to be fixed in 2.0.50 which is stable now. If this bug is not fixed please reopen.
What is in 2.0.50 is the very first patch. Everything in this report starting at comment #3 is still pending.
Bug has been fixed and released in stable portages on or before 2.0.51-r2
Created attachment 71430 [details, diff] portage-2.0-svn20051024-BUILD_PKGS-code.patch Synced with recent portage-2.0 SVN, and made various rewrites/changes: - deprecates FEATURES=buildpkg (resp. buildsyspkg) in favor of BUILD_PKGS="*" (resp. BUILD_PKGS="system"). The feature flags still work though, but with a warning. - added support for shell-like patterns in BUILD_PKGS elements (to match stuffs like "sys-*" or "*/mozilla*") - refactored to put more code in portage.config and less in emerge. It plays better with local USE flags and conditional PROVIDE this way, and is probably a bit cleaner
Created attachment 71431 [details, diff] portage-2.0-svn20051024-BUILD_PKGS-cnf.patch Documentation for cnf/make.conf*
Created attachment 71432 [details, diff] portage-2.0-svn20051024-BUILD_PKGS-man.patch Adds documentation to man/make.conf.5
Reopening now that patches are up-to-date again. Low priority tho, since it's a new feature that most people have been able to live without so far.
(In reply to comment #17) > - added support for shell-like patterns in BUILD_PKGS elements (to match > stuffs like "sys-*" or "*/mozilla*") Nowadays you can use wildcard atoms in /etc/portage/package.env to enable FEATURES=buildpkg for the packages you want.
