New @live-rebuild and @module-rebuild package sets

I’ve implemented new @live-rebuild and @module-rebuild package sets, and added them to the default sets.conf file for the next sys-apps/portage release (that will be 2.2_rc6). Here are the relevant sections from sets.conf:

# Installed ebuilds that inherit from known live eclasses.
[live-rebuild]
class = portage.sets.dbapi.InheritSet
world-candidate = False
inherits = cvs darcs git mercurial subversion

# Installed packages that own files inside /lib/modules.
[module-rebuild]
class = portage.sets.dbapi.OwnerSet
world-candidate = False
files = /lib/modules

Given the new InheritSet and OwnerSet classes, it’s easy to define similar sets based on inherited eclasses and installed files, respectively.

6 thoughts on “New @live-rebuild and @module-rebuild package sets”

  1. This will be pretty neat features.
    However one things that would be nice (maybe worth a bug in bugzilla?) would be to have a @live-update (or something) that checks to see if upstream repo has been updated since last merge and in that case updates it, leaving the rest to be. That way you can run @live-rebuild if you want to rebuild all of them and @live-update if you only want the updated.

    This becouse on some system (like one of mines where I have to get a big chunk of xorg from git for some upstream bughunting) there could be a lot of packages inheriting git that are not very often are updated upstream and there is no need to rebuild.
    I know there are scripts to do this for you but it would be nice to have them all at one place.

  2. However one things that would be nice (maybe worth a bug in bugzilla?) would be to have a @live-update (or something) that checks to see if upstream repo has been updated since last merge and in that case updates it, leaving the rest to be. That way you can run @live-rebuild if you want to rebuild all of them and @live-update if you only want the updated.

    We already have plans to implement this in a future EAPI. See bug 182028.

  3. Some ebuilds are snapshot ebuilds that point to a certain fixed revision, for example:

    ESVN_REPO_URI=”svn://mySvnServer/${PN}@{${PV}}”

    This will never need svn updating, but it is pulled in anyway to @live-rebuild. The solution you have is so elegent, though, that it may not be worth it to fix this outside case.

  4. Well, the @live-rebuild set is really only intended as an interim solution until bug 182028 has been implemented in a future EAPI. See bug 233589 for an alternative way that we might implement @live-rebuild using a new RESTRICT value (that doesn’t require an EAPI bump).

  5. Should note that @live-rebuild may catch packages that inherit those eclasses, but aren’t really “live” packages

    It might be good to add support for RESTRICT=live (with the reverse meaning of what was originally suggested in bug 233589) since it will also be useful for repoman’s LIVEVCS.stable check. I’ve just sent an RFC email to the gentoo-dev mailing list.

Comments are closed.