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 |