Re: [Gnu-arch-users] Features command for arch

[Tom Lord]

    > From: David Allouche <address@hidden>

    > On Sat, 2004-08-28 at 16:22 -0400, James Blackwell wrote:
    > > I brought this one up because David (ddaa of pyarch) is having 
difficulty
    > > predicting tla behavior.  Sometimes, tla acts differently before a bug
    > > is fixed than after. Also, he'd like to know trivially things like
    > > whether or not tla uses pika escaping, etc. 

    > I have already been thinking that "tla features" would be a good thing
    > to have for a long time, and discussed it on #arch. The specific problem
    > that triggered the discussion with jblack was the support of archive-
    > meta-info.

    >       * Up to  recently, archive-meta-info produced no output and exited
    >         with status 0 either if the requested meta-info file was missing
    >         or if it was empty.
    >       * This made it impossible to know whether an archive was signed or
    >         set to use listings because even though make-archive never
    >         create meta-info files with empty content, tla behaviour only
    >         depends on the _existence_ of the file, and there are many
    >         archives in the wild with empty http-blows and signed-archive
    >         files.
    >       * tla was modified so archive-meta-info exit(1) if the file is
    >         missing, exit(0) if it is present and empty, and print nothing
    >         in both cases.
    >       * At this point, "archive-meta-info signed-archive" printing
    >         nothing and exiting with status 0 can mean either "the archive
    >         is signed" (new tla) or "the archive is not signed" (old tla).

    > So PyArch needs to know whether the archive-meta-info fix is present.
    > Currently that is done in a very ugly way: a flag is set in the source
    > code and the test suite checks it for consistence with the observed
    > behaviour of tla.

That is a wonderful explanation and it alone answers all the immediate
questions I can think of about the proposal.

You have convinced me that `features' is a good idea but that some
thought ought to be given as to the nature of `features'.

For example: your particular need could be answered with pretty good
precision if it were known that certain patches were or were not
applied to the sources which produced the binary you are running.
You could also get by just by looking at the version number of the
particular tla binary.

On the other hand, jblack's form of the proposal is just for some
binary flags that you can test and that the tla version you compile
can set.   That's less structured but is also simpler.

How can we figure out a good answer to the question of what a
"feature" is?   Is it really just a binary flag?   Does it relate to
the arch namespace?   Can features be "ordered" in the way that
version numbers are?   Who can assert, who can test, and who can
retract the assertion that a feature is present?   Must the presense
of features always be explicitly asserted or can it be inferred in
some cases?   Are the best answers to these questions likely to vary
over time?  On the basis of all of the answers:  what is our best
guess about what actual hacking work to do on this feature?

-t