This trigger should be in the metadata somewhere, and should trigger portage to not generate Manifest1/digests. This allows us to completely strip digests files from the 2007.0 snapshot, without worrying that user's machines will want to regenerate them every time they try to merge something with FEATURES=digests.
(In reply to comment #0) > This allows us to completely strip digests > files from the 2007.0 snapshot, without worrying that user's machines will want > to regenerate them every time they try to merge something with > FEATURES=digests. One possible solution is to add md5 to the manifest2 digests (as suggested in bug #147699). That way, all of the digests will still be available so that users can still generate the only style digests without have to download *all* of the corresponding distfiles. Assuming that we don't want to add md5 to manifest2, we can trigger the dropping of manifest1 via some metadata in the portage tree. How about if we use an empty file named ${PORTDIR}/manifest1_obsolete to trigger it? The empty file can be added to your rsync snapshot, and we can add it to gentoo-x86 cvs when we decide to drop manifest1 from the cvs tree. The file would be repo/overlay specific, so various overlays could keep or drop manifest1 depending on whether that file has been added to the overlay.
Created attachment 110767 [details, diff] do not generate manifest1 disgests when ${PORTDIR}/manifest1_obsolete exists This patch will prevent generation of manifest1 disgests when ${PORTDIR}/manifest1_obsolete exists (as described in comment #1). In order to drop manifest1 from cvs, will also have to add support to repoman so that it handles manifest1 digest files correctly. Perhaps it should automatically remove them from cvs? (In reply to comment #1) > users can still generate the only style digests without have to download *all* > of the corresponding distfiles. Actually, this doesn't seem to be a problem. Even without a patch, current versions of portage will simply generate the digest files without the MD5.
What about instead checking for a file that exists? We add ${PORTDIR}/Manifest1 and ${PORTDIR}/Manifest2 and we filter the Manifest1 file out, or something. Then we don't have to keep around a manifest1_obselete forever and it'll be extensible for the future if we ever decided to change how Manifest works again. I'm sold, either way, to be honest. If you'd like, I can make a snapshot with this change in portage and delete all the digests to test it.
(In reply to comment #3) > We add ${PORTDIR}/Manifest1 I thought about doing it that way, but I decided against it because it the file is missing for some reason (like somebody didn't do a full cvs up) then portage will not behave as expected. By testing for existence of ${PORTDIR}/manifest1_obsolete, it seems like there is less change of accidentally triggering the manifest1 dropping code. Eventually we will be able to remove the trigger from portage aremove that file from the tree.
Created attachment 110808 [details, diff] repoman support for removal of manifest1 from cvs (In reply to comment #3) > If you'd like, I can make a snapshot with this change in portage and delete all > the digests to test it. Yes, please test. I'll also be testing these patches and hopefully I can release 2.1.2-r11 with them in a couple of days.
Created attachment 110978 [details] repoman support for removal of manifest1 from cvs This patch applies against the 2.1.2 branch of portage. I've fixed a few bugs in repoman while testing it. It's pretty well tested now.
This has been released in 2.1.2-r11.
