--- 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 @@ Title:Manifest2 format -Version:1.2 +Version:1.3 -Last-Modified:2005/12/06 16:19:37 +Last-Modified:2006/01/23 10:24:24 Author:Marius Mauch <genone at gentoo.org>, @@ -54,40 +54,41 @@

Contents

-

Abstract

+

Abstract

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.

-

Motivation

+

Motivation

Please see [1] for a general overview. The main long term goals of this proposal are to:

-

Specification

+

Specification

The new Manifest format would change the existing format in the following ways:

-

Rationale

+

Rationale

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.

-

Removal of digest files

+

Removal of digest files

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.

-

Reducing redundancy

+

Reducing redundancy

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 [2]).

+use, but expected to change soon (see [2]).

-

Removal of checksum collisions

-

The current system theoretically allows for a DISTFILE type file to be recorded +

Removal of checksum collisions

+

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.

-

Flexible verification system

+

Flexible verification system

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:

-

Backwards Compatibility

+

Backwards Compatibility

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.

-

Other problems

+

Other problems

-

Impacts on infrastructure

+

Impacts on infrastructure

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 [3] about 40% of +to some degree (according to a recent research [3] about 40% of all Manifests in the tree are signed, but this number hasn't been verified).

-

Reference Implementation

+

Reference Implementation

A patch for a prototype implementation of Manifest2 verification and partial -generation has been posted at [4], it will be reworked before +generation has been posted at [4], 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.

-

Options

+

Options

Some things have been considered for this GLEP but aren't part of the proposal yet for various reasons:

-

Credits

+

Credits

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.

-

References

+

References

@@ -352,25 +342,37 @@
- +
[2](1, 2) http://thread.gmane.org/gmane.linux.gentoo.devel/33434
[2](1, 2) http://thread.gmane.org/gmane.linux.gentoo.devel/33434
-
[3]gentoo-core mailing list, topic "Gentoo key signing practices +
[3]gentoo-core mailing list, topic "Gentoo key signing practices and official Gentoo keyring", Message-ID <20051117075838.GB15734@curie-int.vc.shawcable.net>
- + + +
[4]http://thread.gmane.org/gmane.linux.gentoo.portage.devel/1374
[4]http://thread.gmane.org/gmane.linux.gentoo.portage.devel/1374
+ + + + + +
[5]http://www.gentoo.org/proj/en/glep/glep-0044-extras/manifest2-example
+ + + +
[6]glep-0044-extras/manifest2-example
@@ -378,7 +380,7 @@