As of 2010-08-27, egencache is able to regenerate use.local.desc file as well as the metadata, using the additional '--update-use-local-desc' action. Our tests show that it performs better than the current scripts, especially in handling whitespace; besides that, it is able to regenerate the gx86 use.local.desc file correctly within near 10 seconds. AFAIK, egencache is already used on the rsync machine in order to regenerate the package metadata. Thus, after upgrading portage there to a version supporting the new features, I think it would be a nice step forward to move the use.local.desc regeneration there through adding '--update-use-local-desc' to the current egencache call.
And what version of portage is required for this feature?
The code I wrote was mostly a giant hack to get it done; so if egencache is better at it I am all for it :) The current code is chillin in cvs: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/users/antarus/projects/infra/ I think the comments preservation is a decent feature, if we could keep that in whatever we migrate to that would be nice ;)
(In reply to comment #1) > And what version of portage is required for this feature? Currently, -9999. Zac promised to sneak it into 2.1.9. (In reply to comment #2) > I think the comments preservation is a decent feature, if we could keep that in > whatever we migrate to that would be nice ;) Will be done in a while.
Ah, and 2.2_rc70+ have this feature too but complete comment saving with be with _rc72+ (it now simply uses a short, hard-coded comment).
I've retested with portage-2.1.9, and: $ egencache --update-use-local-desc --preserve-comments --repo=gentoo does the job fine.
If this bug suggests to move making the end user create the use.local.desc then it's a no go. metadata.xml is allowed to be rsync excluded by the end user.
Currently a cronjob updates use.local.desc and checks it into CVS. I believe the bug proposes that we switch to running egencache at the same time that we generate metadata (on osprey?) -A
(In reply to comment #7) > I believe the bug proposes that we switch to running egencache at the same time > that we generate metadata (on osprey?) Yep, that's the idea. Or, to be more concise, using the same egencache call and adding additional arguments to it to enable the use.local.desc generation.
Ping. Portage-2.1.9 is now stable on almost all arches, so I think we could proceed with the switch.
mgorny: Can you update for the full commandline/env settings to use a specific (non-root) make.conf and specific dir for $PORTDIR for this, then we can update osprey and drop the old file from CVS.
(In reply to comment #10) > mgorny: > Can you update for the full commandline/env settings to use a specific > (non-root) make.conf and specific dir for $PORTDIR for this, then we can update > osprey and drop the old file from CVS. Hm, I guess that would be: egencache --config-root $LOCATION \ --portdir $PORTDIR \ --update --jobs $NJOBS --rsync \ --update-use-local-desc --preserve-comments Where $LOCATION would be the alternate root, and make.conf would be read from $LOCATION/etc/make.conf then (or $LOCATION/etc/portage/make.conf, whichever you prefer). I've added the '--rsync' option but dependending on the particular scenario, it may be not needed. And the new use.local.desc would be in $PORTDIR/profiles (like usual); if you want an alternate location, you can use '--use-local-desc-output $ALTPATH'. And just to make it clear, the following command updates both the metadata cache and the use.local.desc file.
this change is now in the "new" mastermirror code that I have been working on. Not yet used, but running. Will be deployed soonish.
(In reply to comment #12) > this change is now in the "new" mastermirror code that I have been working on. > Not yet used, but running. Will be deployed soonish. > FYI, deployed.
