From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30974 invoked from network); 28 Dec 2003 23:02:45 +0000 Received: from smtp.gentoo.org (128.193.0.39) by eagle.gentoo.oregonstate.edu with DES-CBC3-SHA encrypted SMTP; 28 Dec 2003 23:02:45 +0000 Received: from lists.gentoo.org ([128.193.0.34] helo=eagle.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.24) id 1Aajvo-000600-VA for arch-gentoo-portage-dev@lists.gentoo.org; Sun, 28 Dec 2003 23:02:44 +0000 Received: (qmail 2024 invoked by uid 50004); 28 Dec 2003 23:02:42 +0000 Mailing-List: contact gentoo-portage-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail Reply-To: gentoo-portage-dev@lists.gentoo.org X-BeenThere: gentoo-portage-dev@gentoo.org Received: (qmail 28174 invoked from network); 28 Dec 2003 23:02:42 +0000 From: Daniel Robbins To: gentoo-portage-dev@lists.gentoo.org In-Reply-To: <200312271631.45947.blauwers@gentoo.org> References: <200312271631.45947.blauwers@gentoo.org> Content-Type: text/plain Organization: Gentoo Technologies, Inc. Message-Id: <1072652564.4194.132.camel@music.gentoo.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sun, 28 Dec 2003 16:02:44 -0700 Content-Transfer-Encoding: 7bit Subject: Re: [gentoo-portage-dev] coveted features X-Archives-Salt: 9de3dbab-9016-428d-8bf7-054c4f64df23 X-Archives-Hash: 2f95fc03ac5fcafd4da9167238214ad2 On Sat, 2003-12-27 at 08:31, Bart Lauwers wrote: > 10. ability for a package install to trigger a USE flag(, like evms2 for > instance) This has been supported for quite some time in the current version of Portage. Auto-USE settings are defined in /etc/make.profile/use.defaults. If the package on the right is installed, the USE variable on the left is automatically enabled. This feature is on by default in Portage. It can be turned on or off by overriding the USE_ORDER variable defined in /etc/make.globals. The current default setting of "env:conf:auto:defaults" tells Portage to use the following information to determine USE: 1) first, get USE information from make.defaults 2) then, consult use.defaults and enable any USE vars based on what packages are installed. 3) then, consult /etc/make.conf and apply the settings ("-foo bar") to the USE settings so far. 4) then, consult USE in the current environment (environment variable) and apply the settings ("-cow moo") to the use settings so far. This results in the current USE settings. I do think that not too many people know about auto-USE, so it is somewhat under-utilized. > 12. Package names are too inflexible for version numbers. It is clear the > assumptions in portage do not match or allow for all naming schemes vendors > might have. There needs to be a simple way to identify vendor releases so that > it is clear from a portage search which actual version the user will be > installing of the package. Having a somewhat rigid versioning scheme can actually be a good thing, as Portage needs to be able to determine if a particular version of a package is "newer" than another. If we support all possible versioning schemes, it will be hard to determine if some version strings are newer than others. So we need to have some kind of standard versioning. Otherwise, how do you tell if "foo-1a" is newer, older or the same as "foo-a1," etc. As long as this requirement is kept in mind, we can look at ways at expanding the version syntax. > 13. Add a tripwire / md5 or crc feature to portage so it can check the entire > system for consistency with it's database and report discrepancies. This will be added to our requirements doc. > 15. Better design for supporting many architectures and OS targets (why not > have a portage for cygwin? or one for Solaris?) Will be supported from the beginning. > 16. separation of all user interface and functional components so that > graphical installers can be built/adjusted easily on top of portage. Will be done from the start. > 17. ACCEPT_LICENSE="..." We will have a generic masking model that will allow masking decisions to be made based on any part of metadata. So this will be supported out of the box. > 21. ability for portage to back up any file overwritten so an undo option can > be created (allowing one to backtrack to past states) I will be making sure this gets added. > 22. support for xdelta or the likes on source files, we download way more then > we should for keeping a system up to date We will have a plugin or component model for fetching files, which will allow a plugin or component to be written to do this. We'll keep thing sufficiently abstract so that this is possible. > 23. run checks only on uncompressed files so users can recompress archives at > their leasure in different formats if desired. (so source urls should > probably not include an extension for compression or know how to verify for > recompressed sources in other formats before downloading) I think this would be a good design goal. Haven't ignored your other requests, just commenting on a handful atm :) Regards, Daniel -- gentoo-portage-dev@gentoo.org mailing list