1 |
On Mon, 24 Jul 2006 06:23:59 -0700 |
2 |
Brian Harring <ferringb@×××××.com> wrote: |
3 |
|
4 |
> On Mon, Jul 24, 2006 at 02:47:46PM +0200, Kevin F. Quinn wrote: |
5 |
> > On Sun, 23 Jul 2006 12:19:28 +0100 |
6 |
> > Stuart Herbert <stuart@g.o> wrote: |
7 |
> > > Just adding an alias |
8 |
> > > into a second category makes the tree more of a mess - not less. |
9 |
> > |
10 |
> > The alias, once setup, can be left alone forever. As far as any |
11 |
> > further maintenance is concerned, it requires none. Even if the |
12 |
> > package is moved again, the alias can still point to the second |
13 |
> > location which becomes an alias for the final location. |
14 |
> |
15 |
> That implicitly means that any second level categorizations can never |
16 |
> be removed. |
17 |
|
18 |
By "second level categorizations" do you mean the intermediate alias? |
19 |
The intermediate alias will exist anyway, as an alias in its own right. |
20 |
|
21 |
If any alias is to be removed, then clearly any references to it need |
22 |
to be cleaned up. This is the case whether the alias in question is |
23 |
part of a chain or not. Also this is no worse a situation than current |
24 |
package moves - a fixpackages-style patch-up becomes necessary at that |
25 |
point (more on removal below). |
26 |
|
27 |
Having said all that, I do think the single alias file approach would |
28 |
be better, and it would be simple then to require all aliases to refer |
29 |
directly to the real category. This would indeed require some |
30 |
maintenance, but not exactly back-breaking, just one file for the |
31 |
maintainer of the package that is being moved to check for existing |
32 |
aliases to the previous location. |
33 |
|
34 |
> Like stuart said, makes a bigger mess of the tree. Package moves can |
35 |
> be disruptive enough- trying to shift out a non-real category is |
36 |
> going to be a much larger mess of building that tree and trying to |
37 |
> rewrite atoms as needed. |
38 |
|
39 |
I disagree, it's not a mess. It's better for existing installations as |
40 |
the old CP still works - so to my mind you get the best of both worlds; |
41 |
you can move the package to whatever category the maintainer thinks is |
42 |
the best, without having to hack around all over the place (which |
43 |
currently leaves standalone installations in the dark, btw) to clean up. |
44 |
|
45 |
> > As far as |
46 |
> > users are concerned, assuming aliases are resolved when being |
47 |
> > parsed, they would see: |
48 |
> > |
49 |
> > $ emerge -p net-im/skype |
50 |
> > |
51 |
> > These are the packages that would be merged, in order: |
52 |
> > |
53 |
> > Calculating dependencies... done! |
54 |
> > [ebuild R ] net-voip/skype-1.3.0.30-r1 |
55 |
> |
56 |
> That doesn't strike you as a bit... daft? they asked for net-im, not |
57 |
> net-voip. Yes, under your scheme, they're the same- that still is |
58 |
> far from intuitive. |
59 |
|
60 |
No, it seems simple enough to me. Someone who has previously installed |
61 |
skype from the net-im category, may remember it was in net-im and type |
62 |
the command I illustrated. However the package has moved to net-voip, |
63 |
and emerge has done the right thing - managed the alias and gone to the |
64 |
correct package. If you really wanted to be verbose about it, it could |
65 |
go like: |
66 |
|
67 |
$ emerge -p net-im/skype |
68 |
|
69 |
These are the packages that would be merged, in order: |
70 |
|
71 |
Calculating dependencies... done! |
72 |
[ebuild R ] net-voip/skype-1.3.0.30-r1 [*] |
73 |
|
74 |
[*] package moved |
75 |
|
76 |
to highlight to the user the package has moved. Currently that same |
77 |
user would do: |
78 |
|
79 |
$ emerge -p net-im/skype |
80 |
|
81 |
These are the packages that would be merged, in order: |
82 |
|
83 |
Calculating dependencies |
84 |
emerge: there are no ebuilds to satisfy "net-im/skype". |
85 |
|
86 |
[bum - where has Skype gone? hmm; perhaps it's somewhere else] |
87 |
|
88 |
$ <insert favourite package searching mechanism here> |
89 |
$ emerge -p net-voip/skype |
90 |
|
91 |
... |
92 |
|
93 |
Note that since alias names would be ignored if the category is not |
94 |
specified, 'emerge -p skype' would just work in the way it does now. |
95 |
|
96 |
Note also that if a new package is added with the same name, and that |
97 |
package goes in what was once an alias location, the package manager |
98 |
requires you to specify which one you want. |
99 |
|
100 |
|
101 |
> > The only "mess" is that we end up with the alias data in the tree |
102 |
> > and that gradually accumulates. |
103 |
> |
104 |
> Err... cruft accumulating in the tree is a no go. |
105 |
|
106 |
What, like eclasses and ChangeLogs? |
107 |
|
108 |
It's history, rather than cruft. It has meaning to existing |
109 |
installations, as does legacy code in eclasses. I illustrated |
110 |
elsewhere that it could easily be implemented by a simple text file, |
111 |
nothing more intrusive than package.mask et. al. |
112 |
|
113 |
> > However it won't change once it's first |
114 |
> > setup so won't incur any significant synchronisation overhead |
115 |
> > (beyond the overhead for the actual move as done currently). |
116 |
> |
117 |
> A) potential of circular aliasing (fun fun) |
118 |
|
119 |
Circular aliasing is obviously broken and should not be committed. Any |
120 |
such occurrences should be fixed promptly, and the committer slapped. |
121 |
It's also easy to detect. |
122 |
|
123 |
However it's a good reason to require all aliases to be direct (i.e. no |
124 |
aliases of aliases). |
125 |
|
126 |
> B) potential of aliasing multiple pkgs to the same cat (fun fun) |
127 |
|
128 |
Ditto :) |
129 |
|
130 |
> C) pkgs that grow capabilities after a certain version, thus they now |
131 |
> belong in a new category. Now we require full atoms for aliasing |
132 |
> (which means lookup gets more complicated now, and slower) |
133 |
|
134 |
Huh? If the package name changes, then it's a new package anyway. |
135 |
I'm assuming that an alias is from C1P to C2 (possibly C1P1 to C2P2 |
136 |
although I don't think that would be useful) |
137 |
|
138 |
> D) all tree access now must pass through aliasing. Additionally, now |
139 |
> all equality tests must now rely on aliasing to determine if two |
140 |
> pkgs from seperate categories are actually the same pkg (slower, and |
141 |
> far more complicated) |
142 |
|
143 |
This is trivial. As I described earlier, all parsing of CPs from |
144 |
command line, ebuilds or vdb gets aliases resolved to the canonical, or |
145 |
real, package location. Thereafter everything continues as it does |
146 |
now - equality tests are performed on the canonical CP so don't have |
147 |
any trouble. |
148 |
|
149 |
If we follow the ${PORTDIR}/profiles/alias idea resolving CPs to |
150 |
canonical form means a simple lookup; hardly heavy duty stuff - and |
151 |
it could be decided that the alias file always resolves to the real |
152 |
category location rather than permitting aliasing of aliases (which may |
153 |
be a good idea anyway). |
154 |
|
155 |
Some reverse aliasing is needed for purging previous data from the vdb, |
156 |
something I'd not thought of before, but that's not difficult |
157 |
(certainly not a show-stopper). |
158 |
|
159 |
> Fair amount of thorny issues introduced there, for (imo) no real gain. |
160 |
> |
161 |
> > I've mentioned the |
162 |
> > <CP>/alias idea elsewhere, however that's not the only way to do it |
163 |
> > - one simple method could be to have a simple text file (e.g. |
164 |
> > ${PORTDIR}/profiles/alias) listing all the aliases. That's no mess |
165 |
> > at all: |
166 |
> > |
167 |
> > ---- example alias file contents |
168 |
> > # Alias category/package Resident category |
169 |
> > net-im/skype net-voip |
170 |
> > ---- |
171 |
> |
172 |
> As I said (and you seemed to have ignored), mandating tree access to |
173 |
> use the vdb or a standalone binpkg repository == no go. |
174 |
|
175 |
I didn't ignore it - I didn't get it when you first said it. What |
176 |
you're saying (?) is that to install a binpkg (for example), if the tree |
177 |
is present it would resolve the category that the binpkg was created |
178 |
under (that is now aliased) to the new category using the alias data |
179 |
in the tree, and store stuff in the vdb under that new category, purging |
180 |
out the entry in the vdb from the old category (hence using tree data |
181 |
in the standalone case). Obviously this is the correct behaviour when |
182 |
the tree is present. |
183 |
|
184 |
I'd suggest that in the absence of a tree, operations would assume no |
185 |
aliasing (since all aliases at the time the vdb or binpkg were created |
186 |
would already have been resolved), so the system state is still |
187 |
consistent with the aliasing in force when the packages were built. |
188 |
|
189 |
I can see an issue where a binpkg of the same package created from a |
190 |
later date with a different category won't upgrade cleanly on the |
191 |
standalone system. However package moves as they currently stand don't |
192 |
upgrade cleanly either, so you haven't lost anything. Similarly with |
193 |
inconsistencies introduced into the standalone vdb by such actions. |
194 |
|
195 |
|
196 |
One issue with the single alias config file approach, is that it's easy |
197 |
for someone to commit a package into an alias location without |
198 |
realising it (can't be done with the tree CP/alias approach). I don't |
199 |
know what CVS does when you try to add a directory that previously was |
200 |
deleted; perhaps that gives an indication. If not, it'd be down to a |
201 |
repoman check that commits aren't being made to alias locations. |
202 |
|
203 |
|
204 |
Removals - removing an alias could become problematic, particularly if |
205 |
the alias location is re-used for another package (which would be the |
206 |
only good reason for removing an alias, after all). Any existing |
207 |
references to the alias location would now become real, so these would |
208 |
need to be fixed up in the tree and in the vdb, binpkgs in much the |
209 |
same way as package moves require vdb fixups today. This is not |
210 |
solvable for standalone (i.e. no-tree) machines which get updated from |
211 |
binpkgs built elsewhere, but again this problem exists for package |
212 |
moves and isn't solved there either. It's worth thinking about that |
213 |
issue for tree-present systems; it indicates keeping vdb up-to-date |
214 |
with current aliasing is necessary. I'll think about that. |
215 |
|
216 |
-- |
217 |
Kevin F. Quinn |