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

[James Blackwell]

Tom,

Please read my email on the new release process.


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?

Two of those versions confuse frontends because of the broken return
code.

Three of those versions have checksums

Three of those versions have subtlely broken file ids. 

The fact of the matter is that yes, somebody's got to keep a table of
what works how where. 

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.

So we do that. What's that buy us? Instead of one table with arch,
filled in by the people that authoritively know what the various
differences are between the various versions, we've got 10 frontend
authors writing 10 tables. We've also got 10 frontend authors that we've
got to keep in step with, informing them of when there are changes.

> 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.

Are *you* making a KISS claim? Seriously? 


> 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?

Yeah. I think you're kidding.

There's no question that the front end guys *must* test. The question is
how easy we make the work for them.

For example, they'll need to test whether its the newest tla (that can
distinguish between an empty meta-info or no meta info) or the
not-quite-so-new tla (can not distinguish)

For example, whether or not this tla has checksums, ( >=1.2.0 yes,
otherwise no).

For example, whether or not tla supports sha1 (<=1.2.1 no, >= 1.2.2
maybe). 

For example, whether or not the front end should warn about storing
a revision library on nfs ( < 1.2.1 no, >= 1.2.1 yes)

Sure, we can cop out and just give a reliable, machine readable
"tla version" command. But if we don't track the subtle behavior
changes for them, then they will have to.

> 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?

In the last three versions, I can think of no less than six qualifying
examples.

I'd say its pretty clear that we need to do *something*. This is the
idea I came up with. If you can come up with a simpler one that
addresses the problem almost as well, lets talk about it. :)

> 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.

1. A bug by its very nature is unpredicted.

2. A bug by its very nature has already broken the contract for a 
"fixed set of 'features'" and the code doesn't work the way its defined
to work. Here's our choices: 

A) Either we change the code that that it works as defined, causing 
   a change that must be tracked by front ends 
   
B) Or change the contracted defintion. We're now contractually obligated
   to maintain a bug. Thats kind of like this: 
   
   Definition: A floor is a level surface that you can walk across
   Bug: The carpenter left a hole in the floor
   New Definition: A floor is a level surface that you can walk across,
                   unless there happens to be a hole in this particular
                   spot that you can fall through.

If we go this way (what I'll term the Microsoft way, who is well known
for sacrificing a clean interface for a bug-for-bug interface), then
twenty years from now we'll be stuck with the arch equivilant of 8.3
filenames and 640K of low memory.

-- 
James Blackwell          Try something fun: For the next 24 hours, give
Smile more!              each person you meet a compliment!

GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400