1 |
On Sunday 22 January 2006 13:02, Marius Mauch wrote: |
2 |
|
3 |
> Well, posting YAIP (yet another implementation plan) won't really help |
4 |
> either. |
5 |
|
6 |
Correct, plans never seem to go anywhere in regards to this... |
7 |
|
8 |
> Don't see the goal here, just the constraints. Are you after a |
9 |
> non-moving tree, a tree with just security fixes, visibility filters in |
10 |
> portage, a new `emerge moo` graphics, ... ? |
11 |
|
12 |
The existing tree with additional functionality. Implemented via a new |
13 |
revision type. |
14 |
|
15 |
> > > No point, would rather add a RSYNC_OPTS var finally instead, which |
16 |
> > > gives the same functionality (and much more). |
17 |
|
18 |
> Yeah, RSYNC_OPTIONS would remove all that hardcoded stuff and put it in |
19 |
> make.globals instead. |
20 |
|
21 |
From make.globals: |
22 |
|
23 |
# ***************************** |
24 |
# ** DO NOT EDIT THIS FILE ** |
25 |
# *************************************************** |
26 |
# **** CHANGES TO make.conf *OVERRIDE* THIS FILE **** |
27 |
# *************************************************** |
28 |
# ** Incremental Variables Accumulate Across Files ** |
29 |
# ** USE, CONFIG_*, and FEATURES are incremental ** |
30 |
# *************************************************** |
31 |
|
32 |
> I removed the warning in gentoolkit-2.1 (wanted to do that for quite |
33 |
> some, just didn't get around to do it). What kind of inconsistent |
34 |
> results are you speaking of? |
35 |
|
36 |
http://www.gentoo.org/proj/en/portage/glsa-integration.xml, section on known |
37 |
problems. |
38 |
|
39 |
The plan is nice. It does not, however, address the needs of some users to |
40 |
have a STABLE system as well. Some users can't willy nilly upgrade to the |
41 |
next version of a package because they might have requirements to stay at |
42 |
the same version. Through something as simple as adding a new revision |
43 |
specifier, a framework can be in place to backport security fixes or ONLY |
44 |
apply revisions that are security related... |
45 |
|
46 |
> Still has issues as this allows for multiple equal versions to exist |
47 |
> (as -rX == -sX). And no, it could not be used immideately in the tree |
48 |
|
49 |
In this case the s is seen as more recent (I have already tested it). If |
50 |
there is a -r5 and a -s5 package, the -s5 package is seen as the most |
51 |
recent. The depgraph must be sorting alphabetically. You could, in |
52 |
effect, migrate towards having revbumps that only add security fixes as -s. |
53 |
Revbumps that are trivial (becoming stable in another arch) could continue |
54 |
being -r. Either way, if they were exact copies of the same ebuild, no |
55 |
harm, no foul. |
56 |
|
57 |
> as unaware portage versions would fail with interesting errors (see |
58 |
> glep 45 for background info), same reason the versioning extensions in |
59 |
> 2.1 can't be used yet (even if 2.1 would be stable). And I'm quite sure |
60 |
> that if this would be used in the tree we'd hit versioning screwups |
61 |
> sooner or later (-sX -> -rX+1 -> -rX+2 -> -sX+1). |
62 |
|
63 |
Damn you, damn you all to hell! |
64 |
|
65 |
> I didn't claim that all/the majority of revbumps are security related. |
66 |
> And there is a way to distinguish the different kind of revbumps: read |
67 |
> the changelog. |
68 |
|
69 |
Hah hah, funny. |
70 |
|
71 |
> Well, it "only" needs a way to feed a set of nodes into the dep |
72 |
> resolver. But that in turn is quite a task as the dep resolver code is |
73 |
> nasty. |
74 |
|
75 |
I have looked at the dep resolver and don't want to go near it with a 10 |
76 |
foot pole. I only want to do the functional equivalent of filtering out |
77 |
anything but "*-sX$" (pseudo regex) during the final doemerge or when |
78 |
displaying in case of --pretend. |
79 |
|
80 |
> What functionality does it actually add? The changes you described so |
81 |
> far just allow multiple letters as revision prefixes. The main thing of |
82 |
> your proposal was probably to limit updates to -s updates, and that's a |
83 |
> tricky goal. |
84 |
|
85 |
It enables ebuild maintainers to backport security patches. It allows them |
86 |
to fix security problems that are not glsa alerts. It does not require the |
87 |
use of a new tool or integration of glsa into portage. It allows users to |
88 |
distinguish between revbumps of a trivial nature and revbumps of a security |
89 |
nature. |
90 |
|
91 |
> Wow, allowing multiple letters for revision prefixes counts as creating |
92 |
> a framework theses days ;) |
93 |
|
94 |
Yes, I believe it can. The same way -r is a framework for updating existing |
95 |
packages. |
96 |
|
97 |
> Again, you haven't touched the resolver yet, so you're not filtering |
98 |
> anything out so far. And that is the crucial part here as far as I |
99 |
> understand your proposal. |
100 |
|
101 |
Working on it... What a nightmare. I don't want to touch the resolver |
102 |
code, only call a different altlist to pass to mydepgraph.merge() or |
103 |
mydepgraph.display() that filters out anything but -sX packages. I am also |
104 |
learning python as I go. |
105 |
|
106 |
Something along the lines of: |
107 |
|
108 |
emerge glsa-updates (new action) |
109 |
internally do an emerge -Du world to get the depgraph |
110 |
filter final call to act only on -sX packages |
111 |
|
112 |
Like you said, that appears to be the not-quite-so-simple part of my master |
113 |
plan :) |