Re: [gentoo-portage-dev] portage-ng requirements doc

[Paul de Vrieze]

Below I'll give my shot at it.

On Friday 28 November 2003 19:55, Daniel Robbins wrote:
> architecture requirements:
>
> 1) facilitate parallel, community development
> 2) allow for easy extensibility and new feature additions over time
> 3) provide a coherent model for (meta)data representation and storage
> 4) will run on a wide variety of systems
> 5) will run efficiently even on modest hardware
> 6) in as much as possible, encourage and/or enforce the development of
> high-quality, versatile and maintainable code
> 7) encourage/enforce separation of package metadata from specific build
> steps and algorithms
> 8) allow for delivery of feature set that meets or exceeds expectations
> of existing user community
>
> design goals:
>
> 1) reflect the sensibilities of "ports" system designs
> 2) provide an easy-to-understand developer API
> 3) provide an open, transparent architecture that reflects UNIX design
> philosophy
> 4) In every way possible, program should be malleable to allow
> conformation to user needs and expectations,
> both interface as well as the specific actions performed by the program.

implementation goals:
1) Support distfile renaming or distfile subdirectories or both to solve the
   name-clash problem.
2) Support useflag and slot dependencies as layed out by carpaski before and
   which will probably come into the current portage.
3) A full dependency tracker that can use the USEFLAGS from compile-time
   instead of check-time to determine dependencies and stale packages. (Should
   make depclean work)
4) Support partial overlap of same-version/same-package packages. This would
   require some extra variable like EXTRASLOT (for example php would specify
   a value like apache2 for the apache2 module and apache1 for the apache1
   module). This variable can be determined at the compilation time based on
   other parameters. The package database needs some name mangling (shouldn't
   be a big problem). Further there needs to be some overlap detection. What
   this would mean is that at the moment a second package of the same version
   but with a different EXTRASLOT would be merged, the overlapping filenames
   would be collected. Those would go in a general package. The ones from the
   original package that do not overlap go to a new package specific to that
   EXTRASLOT, and the files that are new go into the package with the new
   EXTRASLOT.

   Why is this important. It allows for a package like php to be compiled as
   both a plugin to apache1 as to apache2 without any difficulties. It is also
   the solution for modules like alsa and nvidia drivers, and it eases
   cross-compiler installation.
5) Make the ebuild format as extendable as possible (without breaking all
   current ones) to allow for future enhancements.
6) (sidestep) Make a clear system for specifying the locales that should be
   built, and if a specific locale needs to be chosen, what is the priority
   list for that. This will make locales in things like kde and openoffice a
   lot easier, but it also should be used by glibc and other ebuilds.

Paul

-- 
Paul de Vrieze
Researcher
Mail: pauldv@××××××.nl
Homepage: http://www.devrieze.net