--- xml/htdocs/proj/en/glep/glep-0044.html 2006/01/23 10:24:24 1.3 +++ xml/htdocs/proj/en/glep/glep-0044.html 2006/02/10 23:26:55 1.4 @@ -32,9 +32,9 @@
This GLEP proposes a new format for the Portage Manifest and digest file system by unifying both filetypes into one to improve functional and non-functional aspects of the Portage Tree.
Please see  for a general overview. The main long term goals of this proposal are to:
The new Manifest format would change the existing format in the following ways:
Addition of a filetype specifier, currently planned are
Future portage improvements might extend this list (for example with types @@ -129,32 +130,9 @@ <filetype> <filename> <filesize> <chksumtype1> <chksum1> ... <chksumtypen> <chksumn>
However theses entries will be stored in the existing Manifest files.-
An actual example for a (pure) Manifest2 file could look like this (using -indentation to indicate line continuation):-
-AUXFILE ldif-buffer-overflow-fix.diff 5007 RMD160 1354a6bd2687430b628b78aaf43f5c793d2f0704 - SHA1 424e1dfca06488f605b9611160020227ecdd03ac MD5 06d23c04b3d6ddfb1431c22ecc5b28f6 -AUXFILE procmime.patch 977 RMD160 39a51a4d654759b15d1644a79fb6e8921130df3c - SHA1 d76929f6dfc2179281f7ccee5789aab4e970ba9e MD5 bf4c9cd9cb7cdc6ece7d4d327910f0cf -EBUILD sylpheed-claws-1.0.5-r1.ebuild 3906 RMD160 cdd546c128db2dea7044437de01ec96e12b4f5bf - SHA1 a84b49e76961d7a9100852b64c2bfbf9b053d45e MD5 b9fe79135a475458ef1b2240ee302ebd -EBUILD sylpheed-claws-1.9.100.ebuild 4444 RMD160 89326038bfc694dafd22f10400a08d3f930fb2bd - SHA1 8895342f3f0cc6fcbdd0fdada2ad8e23ce539d23 MD5 0643de736b42d8c0e1673e86ae0b7f80 -EBUILD sylpheed-claws-1.9.15.ebuild 4821 RMD160 ec0ff811b893084459fe5b17b8ba8d6b35a55687 - SHA1 358278a43da244e1f4803ec4b04d6fa45c41ab4d MD5 15b5c9348ba0b0a416892588256b4cbc -MISCFILE ChangeLog 25770 RMD160 0e69dd7425add1560d630dd3367342418e9be776 - SHA1 1210160f7baf0319de3b1b58dc80d7680d316d28 MD5 732cdc3b41403a115970d497a9ec257e -MISCFILE metadata.xml 269 RMD160 39d775de55f9963f8946feaf088aa0324770bacb - SHA1 4fd7b285049d0e587f89e86becf06c0fd77bae6d MD5 82e806ed62f0596fb7bef493d225712f -DISTFILE sylpheed-claws-1.0.5.tar.bz2 3268626 RMD160 f2708b5d69bc9a5025812511fde04eca7782e367 - SHA1 d351d7043eef7a875df18a8c4b9464be49e2164b MD5 ef4a1a7beb407dc7c31b4799bc48f12e -DISTFILE sylpheed-claws-1.9.100.tar.bz2 3480063 RMD160 72fbcbcc05d966f34897efcc1c96377420dc5544 - SHA1 47465662b5470af5711493ce4eaad764c5bf02ca MD5 863c314557f90f17c2f6d6a0ab57e6c2 -DISTFILE sylpheed-claws-1.9.15.tar.bz2 3481018 RMD160 b01d1af2df55806a8a8275102b10e389e0d98e94 - SHA1 a17fc64b8dcc5b56432e5beb5c826913cb3ad79e MD5 0d187526e0eca23b87ffa4981f7e1765 -+
To maintain compability with existing portage versions a transition period after is the introduction of the Manifest2 format is required during which portage will not only have to be capable of using existing Manifest and digest files but @@ -165,7 +143,7 @@ about.
It is important to note that this proposal only deals with a change of the format of the digest and Manifest system.
It does not expand the scope of it to cover eclasses, profiles or anything @@ -173,16 +151,28 @@ the Manifest signing efforts in any way (though the implementations of both might be coupled).
Also while multiple hash functions will become standard with the proposed -implementation they are not a specific feature of this format .+implementation they are not a specific feature of this format . +
While using multiple hashes for each file is a major feature of this proposal +we have to make sure that the number of hashes listed is limited to avoid +an explosion of the Manifest size that would revert the main benefit of this proposal +(reduzing tree size). Therefore the number of hashes that will be generated +will be limited to three different hash functions. For compability though we +have to rely on at least one hash function to always be present, this proposal +suggest to use SHA1 for this purpose (as it is supposed to be more secure than MD5 +and currently only SHA1 and MD5 are directly available in python, also MD5 doesn't +have any benefit in terms of compability).
The main goals of the proposal have been listed in the Motivation, here now the explanation why they are improvements and how the proposed format will accomplish them.
Normal users that don't use a "tuned" filesystem for the portage tree are wasting several dozen to a few hundred megabytes of disk space with the current system, largely caused by the digest files. @@ -200,17 +190,17 @@ both users and the Gentoo infrastructure.
When multiple hashes are used with the current system both the filename and filesize are repeated for every checksum type used as each checksum is standalone. However this doesn't add any functionality and is therefore useless, so the new format removes this redundancy. This is a theoretical improvement at this moment as only one hash function is in -use, but expected to change soon (see ).+use, but expected to change soon (see ).
The current system theoretically allows for a DISTFILE type file to be recorded +
The current system theoretically allows for a DIST type file to be recorded in multiple digest files with different sizes and/or checksums. In such a case one version of a package would report a checksum violation while another one would not. This could create confusion and uncertainity among users. @@ -219,29 +209,29 @@ As the new format lists each file exactly once this would be no longer possible.
Right now portage verifies the checksum of every file listed in the Manifest -before using any file of the package and all DISTFILE files of an ebuild +before using any file of the package and all DIST files of an ebuild before using that ebuild. This is unnecessary in many cases:
Switching the Manifest system is a task that will need a long transition period like most changes affecting both portage and the tree. In this case the implementation will be rolled out in several phases:@@ -284,9 +274,9 @@ system can selectively be used as soon as step 2) is completed.
While one long term goal of this proposal is to reduce the size of the tree and therefore make life for the Gentoo Infrastructure easier this will only take effect once the implementation is rolled out completely. In the meantime @@ -296,20 +286,20 @@ propagation of Manifest2 capable portage versions among devs or the update rate of the tree. It has been suggested that Manifest files that are not gpg signed could be mass converted in one step, this could certainly help but only -to some degree (according to a recent research  about 40% of +to some degree (according to a recent research  about 40% of all Manifests in the tree are signed, but this number hasn't been verified).
A patch for a prototype implementation of Manifest2 verification and partial -generation has been posted at , it will be reworked before +generation has been posted at , it will be reworked before being considered for inclusion in portage. However it shows that adding support for verification is quite simple, but generation is a bit tricky and will therefore be implemented later.
Some things have been considered for this GLEP but aren't part of the proposal yet for various reasons:
Thanks to the following persons for their input on or related to this GLEP (even though they might not have known it): Ned Ludd (solar), Brian Harring (ferringb), Jason Stubbs (jstubbs), @@ -342,7 +332,7 @@ problems.
|||(1, 2) http://thread.gmane.org/gmane.linux.gentoo.devel/33434|
|||(1, 2) http://thread.gmane.org/gmane.linux.gentoo.devel/33434|
|||gentoo-core mailing list, topic "Gentoo key signing practices +|
|||gentoo-core mailing list, topic "Gentoo key signing practices and official Gentoo keyring", Message-ID <20051117075838.GB15734@curie-int.vc.shawcable.net>|