Re: [Gnu-arch-users] archive/category meta-info

[Tom Lord]

    > From: Doran Moppert <address@hidden>

    > With things like ViewARCH, Alexander's archive list and `tla
    > grab` happening all over the place, I'm feeling the need for
    > some human-readable meta-info attached to archives. The
    > address@hidden syntax is convenient, but a short textual
    > description would make finding which registered archive
    > contained that program whose source I needed to hack on much
    > easier.

    > I know there are probably a dozen reasons not to do this, but
    > could chucking a README or similar in =meta-info be a fairly
    > harmless solution? This could be ignored (mostly) by tla, with
    > the only risk being the developer not updating the README and
    > its info becoming stale ...

    > Not sure how this interacts with the tla grab/announce style of
    > working (if at all), but the stanzas described in cmd-grab.c
    > strike me as awkward anyway.


You can safely stick files named '=README' in an archive and they will
(because of the namespace syntax) not be confused for categories,
branches, or versions by tla.

They also won't be (and shouldn't be) copied by `push-mirror'.  (It
used to be that they were copied by push-mirror -- this was slow an
annoying.  Currently, there's nothing in the interface to archives
that would even permit it.)

The open question is whether or not there should be something similar
but actually integrated into arch, so that I might ask, for example:

        tla cat-readme ARCHIVE/CATEGORY--BRANCH

to get the readme for a branch and so that:

        tla push-mirror

updates modified readme files.   

If so, I think we'd want to consider mapping the readme files into the
namespace, for example, with the readme for the entire archive
being stored as the log messages of:

        X-This--Readme--0.1--patch-<N>

And, yes, if higher-level functionality like grab also wants
"meta-data" in the archive, that should be considered too.  Perhaps:

        X-This--grab-bag-<mangled-name>--<version>--patch-<N>

(In general, if you have meta-data that you want push-mirror to honor,
making that data unversioned will slow-down push-mirror;  if
versioned, why not use the existing mechanisms rather than adding a
new one?   Unversioned purely local meta-data (not copied by
push-mirror) could be unversioned -- but none of the uses for it I've
seen (yet) have been really compelling.)

-t