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

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

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


From: Tom Lord
Subject: Re: [Gnu-arch-users] Features command for arch
Date: Tue, 31 Aug 2004 15:30:06 -0700 (PDT)

    > From: David Allouche <address@hidden>

    > > You could also get by just by looking at the version number of the
    > > particular tla binary.

    > That does not scale. There are more "versions" of tla running
    > around than the released ones. The tla is from some personal
    > branch, it may have more or less "features" than the official
    > release it is based on.  This problem is especially apparent
    > with new or experimental features which have not made their way
    > into a release.
    [....]
    > Generally, it is considered bad practise to infer features from the
    > version number.

Hmmm.

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 will all the possible combinations of features.

When does K.I.S.S. kick in?  Adding `features' *encourages* versions
of arch that are so divergent that the absense of `features' would be
sorely missed;  if not encourages, at least prepares for.   Leaving
`features' out has the opposite effect.

It's easier to write external tools if they don't have to test
`features' all the time.   If I want to maximize, over the medium to
long term, the number * quality of interesting external tools,
shouldn't I reject the `features' idea to keep things simple?

Are special case glitches such as the CLI change you mentioned so
frequent that `features' is really needed?   Or can we safely handle
those glitches on a case by case basis?

Wouldn't simply standardizing a fixed set of "features" accomplish the
same goal, but better?  I.e., make what would otherwise be the output
of the `features' command a well-known constant.

-t




reply via email to

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