Gentoo Archives: gentoo-portage-dev

From: Andrew Gaffney <agaffney@×××××××××××××××××××.net>
To: gentoo-portage-dev@g.o
Subject: Re: [gentoo-portage-dev] portage-ng requirements doc
Date: Sat, 29 Nov 2003 00:51:10
Message-Id: 3FC7EC84.90806@technaut.darktalker.net
In Reply to: Re: [gentoo-portage-dev] portage-ng requirements doc by Paul de Vrieze
1 Paul de Vrieze wrote:
2 > Below I'll give my shot at it.
3 >
4 > On Friday 28 November 2003 19:55, Daniel Robbins wrote:
5 >
6 >>architecture requirements:
7 >>
8 >>1) facilitate parallel, community development
9 >>2) allow for easy extensibility and new feature additions over time
10 >>3) provide a coherent model for (meta)data representation and storage
11 >>4) will run on a wide variety of systems
12 >>5) will run efficiently even on modest hardware
13 >>6) in as much as possible, encourage and/or enforce the development of
14 >>high-quality, versatile and maintainable code
15 >>7) encourage/enforce separation of package metadata from specific build
16 >>steps and algorithms
17 >>8) allow for delivery of feature set that meets or exceeds expectations
18 >>of existing user community
19 >>
20 >>design goals:
21 >>
22 >>1) reflect the sensibilities of "ports" system designs
23 >>2) provide an easy-to-understand developer API
24 >>3) provide an open, transparent architecture that reflects UNIX design
25 >>philosophy
26 >>4) In every way possible, program should be malleable to allow
27 >>conformation to user needs and expectations,
28 >>both interface as well as the specific actions performed by the program.
29 >
30 >
31 > implementation goals:
32 > 1) Support distfile renaming or distfile subdirectories or both to solve the
33 > name-clash problem.
34 > 2) Support useflag and slot dependencies as layed out by carpaski before and
35 > which will probably come into the current portage.
36 > 3) A full dependency tracker that can use the USEFLAGS from compile-time
37 > instead of check-time to determine dependencies and stale packages. (Should
38 > make depclean work)
39 > 4) Support partial overlap of same-version/same-package packages. This would
40 > require some extra variable like EXTRASLOT (for example php would specify
41 > a value like apache2 for the apache2 module and apache1 for the apache1
42 > module). This variable can be determined at the compilation time based on
43 > other parameters. The package database needs some name mangling (shouldn't
44 > be a big problem). Further there needs to be some overlap detection. What
45 > this would mean is that at the moment a second package of the same version
46 > but with a different EXTRASLOT would be merged, the overlapping filenames
47 > would be collected. Those would go in a general package. The ones from the
48 > original package that do not overlap go to a new package specific to that
49 > EXTRASLOT, and the files that are new go into the package with the new
50 > EXTRASLOT.
51 >
52 > Why is this important. It allows for a package like php to be compiled as
53 > both a plugin to apache1 as to apache2 without any difficulties. It is also
54 > the solution for modules like alsa and nvidia drivers, and it eases
55 > cross-compiler installation.
56 > 5) Make the ebuild format as extendable as possible (without breaking all
57 > current ones) to allow for future enhancements.
58 > 6) (sidestep) Make a clear system for specifying the locales that should be
59 > built, and if a specific locale needs to be chosen, what is the priority
60 > list for that. This will make locales in things like kde and openoffice a
61 > lot easier, but it also should be used by glibc and other ebuilds.
62
63 I've got something that should be in the new portage. It needs to be able to download
64 source tarballs in a separate thread while compiling is happening to speed the overall
65 process, much like apt-get for Debian.
66
67 --
68 Andrew Gaffney
69
70
71 --
72 gentoo-portage-dev@g.o mailing list

Replies

Subject Author
Re: [gentoo-portage-dev] portage-ng requirements doc Daniel Robbins <drobbins@g.o>