|Summary:||[PATCH] DateSet class for packages emerged before/after a specified date|
|Product:||Portage Development||Reporter:||Martin Väth <martin>|
|Component:||Enhancement/Feature Requests||Assignee:||Portage team <dev-portage>|
|Package list:||Runtime testing required:||---|
|Bug Depends on:|
|Bug Blocks:||144480, 210077|
|Attachments:||Patch for DateSet class; instructions/example how to use it|
Description Martin Väth 2012-09-02 18:51:03 UTC
Created attachment 322766 [details, diff] Patch for DateSet class; instructions/example how to use it It would be useful to have a @magic-set in portage which contains all installed packages which were emerged before/after a specified "critical" date. This date can e.g. be the date of a sys-libs/glibc update (if for some reasons you have to revert it, you need to reemerge all packages compiled afterwards) or the date of a major sys-devel/gcc upgrade (if after a while you want to make sure that all packages are reemerged with the latest major version). Following a suggestion of genone in http://forums.gentoo.org/viewtopic-t-903444.html I have written a corresponding DateSet class which is similar to the AgeSet class and allows to specify corresponding sets. Details/Examples how to use it are described in the first section of the attached patch. The idea is that you specify the date by using exactly one of the following four options: "seconds" (seconds since epoch) "date" (date in a time.strptime format which you can specify with "dateformat"; default is %x %X) "package" (installation time of the specified atom) "filestamp" (mtime of the specified file or directory) (It would be easily possible to include also "age" in this list to merge the functionality with the existing AgeSet class.) Personally, I think that the "filestamp" option is the most convenient, since the user can then simple touch a certain file he specified when he knows that he will start a "critical" emerge. Note that in contrast to e.g. "package = sys-devel/gcc:4.7", the user has in this way full control whether he means the date of the *first* corresponding upgrade of gcc:4.7 or the date of the last minor version upgrade. Of course, it would be even more convenient, if there would exist a class which specifies "all packages emerged while another gcc-version than gcc:4.7 was active", but since the gcc version is not stored in /var/db, such a set cannot be built with current portage.
Comment 1 Zac Medico 2012-09-02 20:20:19 UTC
Comment 2 Zac Medico 2012-09-03 00:04:34 UTC
This is fixed in 2.2.0_alpha124.