From: Andrew Gaffney <agaffney@technaut.darktalker.net>
To: gentoo-portage-dev@gentoo.org
Subject: Re: [gentoo-portage-dev] portage-ng requirements doc
Date: Fri, 28 Nov 2003 18:47:00 -0600 [thread overview]
Message-ID: <3FC7EC84.90806@technaut.darktalker.net> (raw)
In-Reply-To: <200311282315.57449.pauldv@gentoo.org>
Paul de Vrieze wrote:
> 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.
I've got something that should be in the new portage. It needs to be able to download
source tarballs in a separate thread while compiling is happening to speed the overall
process, much like apt-get for Debian.
--
Andrew Gaffney
--
gentoo-portage-dev@gentoo.org mailing list
next prev parent reply other threads:[~2003-11-29 0:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-28 18:55 [gentoo-portage-dev] portage-ng requirements doc Daniel Robbins
2003-11-28 22:15 ` Paul de Vrieze
2003-11-29 0:47 ` Andrew Gaffney [this message]
2003-11-29 1:41 ` Daniel Robbins
2003-11-29 1:51 ` Daniel Robbins
2003-11-29 2:01 ` Lisa Seelye
2003-11-29 5:01 ` Marius Mauch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3FC7EC84.90806@technaut.darktalker.net \
--to=agaffney@technaut.darktalker.net \
--cc=gentoo-portage-dev@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox