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

[Tom Lord]

    > From: [various]

    [ A "features" feature is really desirable because several of us
      are running into the kinds of problem that such a feature can 
      solve. ]


Ok, suppose that we accept that.... that still leaves the question of
what *is* the "features" feature?

An answer implies/includes, to name a few things, how feature names
are decided, who/how feature presense/absense is asserted, what valid
feature names are, etc.

James' suggestion was something like named boolean flags, set I
presume in a static array in some C file --- is that about right?

Even if I believe in the need for "features", that approach seems 
a little random, to me, on at least a few grounds.

Such a table is easy to code up an understand, but also easy to make a
mistake with while maintaining it (a task akin to double checking
somebody's arithmetic at adding up a long column of numbers).
When I balance my checkbook, I do the math by hand and double check
with a calculator: I'm not sure we can expect people to be so careful
with a centralized "features" table and I'm not sure what the
"features" equivalent of a calculator (for double checking) would be.

Next: I like to be frugal with new design add-ons.   If it's *really*
necessary to add something new, hopefully it should solve lots of (or
a very general) existing problems.   "Features" seems a bit isolated
to me, in this context.   

For example: revision libraries have parameter settings (e.g., the
greedy and sparse flags).   Should "features" variables *really* be a
fundamentally different thing?  or is there usefully some more general
concept that would make "features" and revision library params the
same thing?

And of course -- the old questions -- are features really just
booleans?   who controls the namespace of them and how?

-t







    > From: Jason McCarty <address@hidden>

    > James Blackwell wrote:
    > > Tom Lord wrote:


    > > > [....]Asking for `features' in `tla' suggests that we suddenly expect 
*lots*
    > > > of users to all be running slightly different versions of arch, some
    > > > with such and such feature, some without ---- *AND* ----- we expect
    > > > that situation to get *so* out of hand that many external tools have
    > > > to deal [with] all the possible combinations of features.
    > > 
    > > What? You don't think that's happening? How many are running 1.1.5?
    > > 1.2.0? 1.2.1? What about when 1.2.2 comes out?
    > > [...]
    > > Sure, we can offload the work to the frontends to track it, but that
    > > means writing code anyways. The current --version is completely broken
    > > for this task. With buildcfg -r, you get one version string. With
    > > buildcfg -r, you get a different string (not a version string at all).
    > > If you use a tla that comes with a distribution, then it's been screwed
    > > with in godawful ways.
    > 
    > I have to agree with James; the syntax of about 20 commands changed
    > between 1.1 and 1.2, and testing --version isn't completely reliable. I
    > resort to letting the user specify the version, or assume 1.3 when I
    > can't tell.
    > 
    > -- 
    > Jason McCarty <address@hidden>
    > 
    > 
    > _______________________________________________
    > Gnu-arch-users mailing list
    > address@hidden
    > http://lists.gnu.org/mailman/listinfo/gnu-arch-users
    > 
    > GNU arch home page:
    > http://savannah.gnu.org/projects/gnu-arch/
    > 
    >