Re: [Gnu-arch-users] feature plans from over here....

[Tom Lord]

    > From: David Allouche <address@hidden>

    > Great. I had the impression that you were thinking about going for an
    > "explicit role" solution at the exclusion of a "contextual role".

I wasn't but, I also didn't (until this message) quite appreciate what
you meant by "contextual role".  :

    >   3. Roles can be assigned to subsets of the namespace, and be used
    >     automatically.

    >   4. Subsets of namespace can be defined by pattern matching.
    >     for example */pyarch--* will match any pyarch branch anywhere,
    >     where aliases such as "release", "public", "rocketfuel",
    >     "personal" all make sense as important partner versions.

is an interesting idea.  It's a little bit "circular" once archive
registrations are per-hat but not necessarily in a bad or
self-inconsistent way.


    >   5. There is a mechanism for reuse. For example roles applying to
    >     overlapping subset of the namespace could be reconciled using a
    >     precedence order specified explicitly.

    > Apparently, the 3 last points are part of "not just now, yes as
    > extension". That's all right, as long as the underlying design is
    > friendly to such developments.

    > Note: point (4) will tell you something about why I think archive
    > registration must not be done multiple times. Wether I am wearing my
    > pyarch maintainer hat or wearing my employee hat, I still want to
    > access both my private and work archives because they both contain
    > pyarch branches.

My thinking has been:

The arch-params database should have a hat-independent table of known
archives, grouped in equivalence sets of archives that are mirrors of
one another.  Generally, the official name of an archive shoud be
usable to refer to any of its locations (in combination with some
disambiguator that is not part of the archive name).

In other words, just to draw a picture, instead of:

        address@hidden          /usr/lord/...
        address@hidden     http://....
        address@hidden     http://....

it will be more like:

        address@hidden
          rw: /usr/lord/....
          ro: /fastdisk/...
          mirrors:
            a) http://....
            b) http://....
            c) /fastdisk/...  (pull on demand)

Those records will be shared by all of your hats and are closest in
form and function to today's simple archive registrations.  You'll
be able to use archive names (syntax not determined yet) such as:

        address@hidden    # mirror (b) of that archive

The arch namespace is global but that doesn't mean that everyone
actually uses it the same way.   As a result, there is the theoretical
possibility (not all that unrealistic, if you ask me) of winding up
having to deal with distinct archives (not mirrors of one another)
having the same official name.   tla should gracefully handle such
cases, if it can.

Therefore, the hat-independent archive database does have to allow
multiple entries having the same name (and a disambiguating syntax is
needed for that too).

Each hat can then, as discussed, pick a subset of the known archives
as its "per hat registrations".   That can, as you noted, lead to a
smaller output from `tla archives' (very handy if, say, you are a
supermirror managing a few thousand archives).   It's also where we
can iron out the possibility of distinct but same-named archives:
within a hat, names must be unique.

Aliases (for archives, packages, whatever) are sort of orthogonal to 
the above, but they fit in nicely with it.   I was thinking we'd add
global and per-hat aliases.

Aliases serve two functions: they can be used simply, by users, just
to reduce typing.  But aliases are also useful for "object oriented
programming" in which the "objects" are arch hats.   For example, a
"GCC tester" hat might be any hat which has version aliases named
"mainline" and "test-points".    People can then exchange shell
scripts (and the like) for use by GCC testers, those scripts
performing arch operations in terms of those aliases rather than on
hard-coded archive names.

You (ddaa) say that you want inheritence or some other form of reuse
among hats (if i understand you correctly).   I agree but I'm not sure
how "fully general" a mechanism is needed.   Global and per-hat
defaults for a few things.... *maybe* "hats and subhats".

The other form of inheritence I'd like is the ability to
(intelligently) merge in portions of my arch-params settings from
recommended settings provided upstream.   Textual merging is wholly
inappropriate for this but the rules for domain-specific merging
appear to me to be easy to express.


    > What happens with "uninted recursive arch invocation" when you are
    > using _only_ --params? I think you will to use the custom arch-params.
    > However, I do not see how to pass the location of the current
    > arch-params to hook script if not using $ARCH_PARAMS.

It's ok for tla to pass the arch params to hooks to scripts and the
environment is as reasonable a place to do that as anywhere.
It's not desirable for tla to *read* that environment variable for
the path setting.


-t