gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: Automatic archive discovery, take 1


From: Tom Lord
Subject: Re: [Gnu-arch-users] Re: Automatic archive discovery, take 1
Date: Mon, 15 Dec 2003 07:52:06 -0800 (PST)


    > From: Andrew Suffield <address@hidden>

    >> I think it aimed to make a kind of built-in-rdist but instead hit the
    >> target of poorly-designed-name-authority-for-archives.

    > Careful, it's deliberately non-authoritative (unlike, say, DNS);
    > everything stems from the root archive list in the user's ~, and is
    > trivially overridden.

That's a property of your perl program -- not a property of the hook.

The next thing that happens if, say, I add the hook and maybe put the
perl program in a contrib directory, is that someone modifies the perl
program to hit up a server and someone else sets up a web page with
some "official list of archives".

The patch to archive.c looks just like a call-out (via an hook) to a
naming authority (albeit one that can be locally overriden with
register-archive and one that locally memoizes resolutions until the
user explicitly removes them).   The naming authority it implies is
keyed on archive names which, as you note, is a mistake:


    > In more practical terms, I can think of no way to take an
    > archive name and figure out the owner, short of consulting an
    > arbitrary list. They just don't embed anything else that's
    > useful.

Right, and that's deliberate.   My thinking is that, for example,
Linus could quit the OSDL in a huff and then it would be the larger
community, not he or his employer, who decide the "ownership" of the
archive names he was using (if there was contention over them).  Among
the possible ways that decision could come out are "no clear owner --
that name denotes a part of the arch namespace which is no longer
coherent across the entire community".  (For development purposes,
it's unlikely there'd be any good reason for namespace contention --
for other purposes, such as automated source distribution, there may
be very good reasons.  E.g., as Linus walks out the door, does he say
to distribution managers "I think those guys are going down an
unacceptable path -- please disconnect your mirrors from osdl sources
and I will set up a new source on savannah.")

Although I don't like the details of Walters' "meta-archive" proposal
as it stands, one abstract aspect of it that I do like is that it
attempts to make a higher-order namespace for naming some _thing_ that
is more general than just a specific archive name.

For a naming service, I think I'd want to see some higher order names
which project owners could offer and users either accept or decline on
a one-by-one, non-interfering basis.  (A user might say "Ok arch, the
naming service for OSDL is at http://www.osdl.org/[...] -- now set me
up for the projects in 'osdl/telecom-kernels' (or something like
that).)


    > Certainly a system like DNS is useless here. What I've thrown
    > together isn't great, but it's simple and works and easy to
    > extend; I figure it's as good a starting point as any (in the
    > same sense that /etc/hosts is a good starting point for host
    > resolution). Better ideas are invited.

Can you live without that modification to archive.c?

The `grab' command illustrates the principle of at least requiring a
user to explicitly ask for the records for a specific project from a
specific authority location (rather than implicitly and automatically
looking up everything, on demand, from a single source).  Granted, it
doesn't automate away a registration-step -- but it does let you sum
up multiple registration steps in a single command.  (It also
illustrates the principle of using higher-order names.)

-t





reply via email to

[Prev in Thread] Current Thread [Next in Thread]