Re: [gentoo-portage-dev] coveted features

[Daniel Robbins <drobbins@gentoo.org>]

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