Gentoo Archives: gentoo-portage-dev

From: Daniel Robbins <drobbins@g.o>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] coveted features
Date: Sun, 28 Dec 2003 23:02:45
Message-Id: 1072652564.4194.132.camel@music.gentoo.org
1 On Sat, 2003-12-27 at 08:31, Bart Lauwers wrote:
2 > 10. ability for a package install to trigger a USE flag(, like evms2 for
3 > instance)
4
5 This has been supported for quite some time in the current version of
6 Portage. Auto-USE settings are defined in
7 /etc/make.profile/use.defaults. If the package on the right is
8 installed, the USE variable on the left is automatically enabled.
9
10 This feature is on by default in Portage. It can be turned on or
11 off by overriding the USE_ORDER variable defined in /etc/make.globals.
12 The current default setting of "env:conf:auto:defaults" tells Portage
13 to use the following information to determine USE:
14
15 1) first, get USE information from make.defaults
16 2) then, consult use.defaults and enable any USE vars based on what
17 packages are installed.
18 3) then, consult /etc/make.conf and apply the settings ("-foo bar") to
19 the USE settings so far.
20 4) then, consult USE in the current environment (environment variable)
21 and apply the settings ("-cow moo") to the use settings so far.
22
23 This results in the current USE settings. I do think that not too many
24 people know about auto-USE, so it is somewhat under-utilized.
25
26 > 12. Package names are too inflexible for version numbers. It is clear the
27 > assumptions in portage do not match or allow for all naming schemes vendors
28 > might have. There needs to be a simple way to identify vendor releases so that
29 > it is clear from a portage search which actual version the user will be
30 > installing of the package.
31
32 Having a somewhat rigid versioning scheme can actually be a good thing,
33 as Portage needs to be able to determine if a particular version of a
34 package is "newer" than another. If we support all possible versioning
35 schemes, it will be hard to determine if some version strings are newer
36 than others. So we need to have some kind of standard versioning.
37 Otherwise, how do you tell if "foo-1a" is newer, older or the same as
38 "foo-a1," etc.
39
40 As long as this requirement is kept in mind, we can look at ways at
41 expanding the version syntax.
42
43 > 13. Add a tripwire / md5 or crc feature to portage so it can check the entire
44 > system for consistency with it's database and report discrepancies.
45
46 This will be added to our requirements doc.
47
48 > 15. Better design for supporting many architectures and OS targets (why not
49 > have a portage for cygwin? or one for Solaris?)
50
51 Will be supported from the beginning.
52
53 > 16. separation of all user interface and functional components so that
54 > graphical installers can be built/adjusted easily on top of portage.
55
56 Will be done from the start.
57
58 > 17. ACCEPT_LICENSE="..."
59
60 We will have a generic masking model that will allow masking decisions
61 to be made based on any part of metadata. So this will be supported out
62 of the box.
63
64 > 21. ability for portage to back up any file overwritten so an undo option can
65 > be created (allowing one to backtrack to past states)
66
67 I will be making sure this gets added.
68
69 > 22. support for xdelta or the likes on source files, we download way more then
70 > we should for keeping a system up to date
71
72 We will have a plugin or component model for fetching files, which will
73 allow a plugin or component to be written to do this. We'll keep thing
74 sufficiently abstract so that this is possible.
75
76 > 23. run checks only on uncompressed files so users can recompress archives at
77 > their leasure in different formats if desired. (so source urls should
78 > probably not include an extension for compression or know how to verify for
79 > recompressed sources in other formats before downloading)
80
81 I think this would be a good design goal.
82
83 Haven't ignored your other requests, just commenting on a handful atm :)
84
85 Regards,
86
87 Daniel
88
89
90 --
91 gentoo-portage-dev@g.o mailing list

Replies

Subject Author
Re: [gentoo-portage-dev] coveted features Bart Lauwers <blauwers@g.o>