On Mon, 24 Jul 2006 06:23:59 -0700 Brian Harring <[EMAIL PROTECTED]> wrote:
> On Mon, Jul 24, 2006 at 02:47:46PM +0200, Kevin F. Quinn wrote:
> > On Sun, 23 Jul 2006 12:19:28 +0100
> > Stuart Herbert <[EMAIL PROTECTED]> wrote:
> > > Just adding an alias
> > > into a second category makes the tree more of a mess - not less.
> >
> > The alias, once setup, can be left alone forever. As far as any
> > further maintenance is concerned, it requires none. Even if the
> > package is moved again, the alias can still point to the second
> > location which becomes an alias for the final location.
>
> That implicitly means that any second level categorizations can never
> be removed.
By "second level categorizations" do you mean the intermediate alias?
The intermediate alias will exist anyway, as an alias in its own right.
If any alias is to be removed, then clearly any references to it need
to be cleaned up. This is the case whether the alias in question is
part of a chain or not. Also this is no worse a situation than current
package moves - a fixpackages-style patch-up becomes necessary at that
point (more on removal below).
Having said all that, I do think the single alias file approach would
be better, and it would be simple then to require all aliases to refer
directly to the real category. This would indeed require some
maintenance, but not exactly back-breaking, just one file for the
maintainer of the package that is being moved to check for existing
aliases to the previous location.
> Like stuart said, makes a bigger mess of the tree. Package moves can
> be disruptive enough- trying to shift out a non-real category is
> going to be a much larger mess of building that tree and trying to
> rewrite atoms as needed.
I disagree, it's not a mess. It's better for existing installations as
the old CP still works - so to my mind you get the best of both worlds;
you can move the package to whatever category the maintainer thinks is
the best, without having to hack around all over the place (which
currently leaves standalone installations in the dark, btw) to clean up.
> > As far as
> > users are concerned, assuming aliases are resolved when being
> > parsed, they would see:
> >
> > $ emerge -p net-im/skype
> >
> > These are the packages that would be merged, in order:
> >
> > Calculating dependencies... done!
> > [ebuild R ] net-voip/skype-1.3.0.30-r1
>
> That doesn't strike you as a bit... daft? they asked for net-im, not
> net-voip. Yes, under your scheme, they're the same- that still is
> far from intuitive.
No, it seems simple enough to me. Someone who has previously installed
skype from the net-im category, may remember it was in net-im and type
the command I illustrated. However the package has moved to net-voip,
and emerge has done the right thing - managed the alias and gone to the
correct package. If you really wanted to be verbose about it, it could
go like:
$ emerge -p net-im/skype
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] net-voip/skype-1.3.0.30-r1 [*]
[*] package moved
to highlight to the user the package has moved. Currently that same
user would do:
$ emerge -p net-im/skype
These are the packages that would be merged, in order:
Calculating dependencies
emerge: there are no ebuilds to satisfy "net-im/skype".
[bum - where has Skype gone? hmm; perhaps it's somewhere else]
$ <insert favourite package searching mechanism here>
$ emerge -p net-voip/skype
...
Note that since alias names would be ignored if the category is not
specified, 'emerge -p skype' would just work in the way it does now.
Note also that if a new package is added with the same name, and that
package goes in what was once an alias location, the package manager
requires you to specify which one you want.
> > The only "mess" is that we end up with the alias data in the tree
> > and that gradually accumulates.
>
> Err... cruft accumulating in the tree is a no go.
What, like eclasses and ChangeLogs?
It's history, rather than cruft. It has meaning to existing
installations, as does legacy code in eclasses. I illustrated
elsewhere that it could easily be implemented by a simple text file,
nothing more intrusive than package.mask et. al.
> > However it won't change once it's first
> > setup so won't incur any significant synchronisation overhead
> > (beyond the overhead for the actual move as done currently).
>
> A) potential of circular aliasing (fun fun)
Circular aliasing is obviously broken and should not be committed. Any
such occurrences should be fixed promptly, and the committer slapped.
It's also easy to detect.
However it's a good reason to require all aliases to be direct (i.e. no
aliases of aliases).
> B) potential of aliasing multiple pkgs to the same cat (fun fun)
Ditto :)
> C) pkgs that grow capabilities after a certain version, thus they now
> belong in a new category. Now we require full atoms for aliasing
> (which means lookup gets more complicated now, and slower)
Huh? If the package name changes, then it's a new package anyway.
I'm assuming that an alias is from C1P to C2 (possibly C1P1 to C2P2
although I don't think that would be useful)
> D) all tree access now must pass through aliasing. Additionally, now
> all equality tests must now rely on aliasing to determine if two
> pkgs from seperate categories are actually the same pkg (slower, and
> far more complicated)
This is trivial. As I described earlier, all parsing of CPs from
command line, ebuilds or vdb gets aliases resolved to the canonical, or
real, package location. Thereafter everything continues as it does
now - equality tests are performed on the canonical CP so don't have
any trouble.
If we follow the ${PORTDIR}/profiles/alias idea resolving CPs to
canonical form means a simple lookup; hardly heavy duty stuff - and
it could be decided that the alias file always resolves to the real
category location rather than permitting aliasing of aliases (which may
be a good idea anyway).
Some reverse aliasing is needed for purging previous data from the vdb,
something I'd not thought of before, but that's not difficult
(certainly not a show-stopper).
> Fair amount of thorny issues introduced there, for (imo) no real gain.
>
> > I've mentioned the
> > <CP>/alias idea elsewhere, however that's not the only way to do it
> > - one simple method could be to have a simple text file (e.g.
> > ${PORTDIR}/profiles/alias) listing all the aliases. That's no mess
> > at all:
> >
> > ---- example alias file contents
> > # Alias category/package Resident category
> > net-im/skype net-voip
> > ----
>
> As I said (and you seemed to have ignored), mandating tree access to
> use the vdb or a standalone binpkg repository == no go.
I didn't ignore it - I didn't get it when you first said it. What
you're saying (?) is that to install a binpkg (for example), if the tree
is present it would resolve the category that the binpkg was created
under (that is now aliased) to the new category using the alias data
in the tree, and store stuff in the vdb under that new category, purging
out the entry in the vdb from the old category (hence using tree data
in the standalone case). Obviously this is the correct behaviour when
the tree is present.
I'd suggest that in the absence of a tree, operations would assume no
aliasing (since all aliases at the time the vdb or binpkg were created
would already have been resolved), so the system state is still
consistent with the aliasing in force when the packages were built.
I can see an issue where a binpkg of the same package created from a
later date with a different category won't upgrade cleanly on the
standalone system. However package moves as they currently stand don't
upgrade cleanly either, so you haven't lost anything. Similarly with
inconsistencies introduced into the standalone vdb by such actions.
One issue with the single alias config file approach, is that it's easy
for someone to commit a package into an alias location without
realising it (can't be done with the tree CP/alias approach). I don't
know what CVS does when you try to add a directory that previously was
deleted; perhaps that gives an indication. If not, it'd be down to a
repoman check that commits aren't being made to alias locations.
Removals - removing an alias could become problematic, particularly if
the alias location is re-used for another package (which would be the
only good reason for removing an alias, after all). Any existing
references to the alias location would now become real, so these would
need to be fixed up in the tree and in the vdb, binpkgs in much the
same way as package moves require vdb fixups today. This is not
solvable for standalone (i.e. no-tree) machines which get updated from
binpkgs built elsewhere, but again this problem exists for package
moves and isn't solved there either. It's worth thinking about that
issue for tree-present systems; it indicates keeping vdb up-to-date
with current aliasing is necessary. I'll think about that.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
