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

Re: ideas underlying policy



> Hi,
> >>"Jim" == Jim  <jim@laney.edu> writes:
> 
> >> Why should this be distinct from filing the bug report against
> >> policy?
> 
> Jim> Because it doesn't necessarily follow that if a package has a
> Jim> conflict with policy then policy is flawed.
> 
> 	Really? Why not? 

Because it's simply true! In this case, the package is flawed.

> I think it should be decreed that packages
>  follow a standard, unless following the standard breaks the package,
>  and in that case, the standard is broken since it violates teh axiom
>  that Debian does not distribute broken packages. 

Agreed. Without such a standard which moves as the project progresses, debian 
would not be solid, and I, for one, would not use it in favor of a commercial 
solution like bsdi for our computer lab email/shell/dns server.

By the way, I think the policy that exists should follow each distribution, 
and there should be branches: if a distribution is frozen, then a copy of the 
policy that existed at the time should be frozen with the frozen group of 
packages. Otherwise, changes in policy can make a stable release unstable! So 
each distribution should have its own copy of policy.

> 	What makes you make that statement?
> 
> Jim> A conflict can exist without anything being wrong with policy,
> 
> 	Examples, and justification, rather than a bald statement,
>  please. If there may be a conflict with a standard, without the
>  application or the standard being incorrect, then the whole standards
>  process is flawed. 

I'm not saying "may", I'm saying "can"! I'm simply saying it's possible, not 
that it's good or should be allowed. Policy should address the possibility and 
lay down what should happen in this case. If a conflict exists, the two 
possibilities are: (1) policy is flawed, or (2) the package is flawed.

> 	I think we do need a standard for producing debian packages
>  that can interact and co-operate with each other; and the sheer
>  number of packages militates against forging all possible agreements
>  between all interacting pairs of package; it is far better that all
>  packages follow a standard, and all packages can depend on packages
>  in the distribution following the same standard. Complex co-operative
>  interaction is well nigh impossible otherwise.

Well, at least very difficult... and I don't see that debian needs "very 
difficult"...

> Jim> and policy can be flawed without any package having conflict with
> Jim> policy.
> 
> 	True.
> 
> Jim> Basically, there exist more possibilities than you were
> Jim> originally aware of, but some thought and jotting down all
> Jim> possible permutations will quickly reveal the possibilities that
> Jim> do exist.
> 
> 	Examples.
> 
> 	All possible permutations maynot exist in reality. This is not
>  a puerile exercise in basic logic; this is a standards drafting body;
>  and basic logic that has no basis in reality has little place here. 

Then the developers should agree to follow it... seems there are folx who 
won't do that, especially Dale... I don't see why, really: policy tries to 
capture a combination of current practice and things that are known to work. 
All Dale would have to do is say "my libc package violates policy (since it 
isn't a stripped binary) because if it didn't, none of debian would work 
(since stripped libs are pointless). You didn't know this, only I knew it. Now 
you do, and you should incorporate a clause in policy that handles this, 
because this must be documented so that new people can find this out, and 
experienced people has something to refer to should someone take over libc; I 
thus share this information with debian". To not do so is unreasonable: to say 
"everyone should be able to intuit everything about debian because having to 
follow some "fachist" document that tells me what to do is personally 
difficult" isn't even correct because policy should change as things are 
revealed, and all it takes is to let someone know, let them think and make a 
decision. The libc decision is particularly easy: libs cannot be stripped 
unless you redesign how libs work. So it's extremely likely that policy is (or 
was) flawed in this respect.

Dale: is it fair to withold this information? Is it good for the project?
(I don't know your email addr, otherwise I would have sent this to you as 
well; sorry abt that)

> Jim> A glance at a basic symbolic logic text may be of help:
> Jim> the fact this note expresses is not the result of any debian law,
> Jim> nor can it be denied thereby; it is simply a matter of basic
> Jim> logic.
> 
> 	I shall refrain from comments about ivory towers and reality
>  and pragmatism here.
> 
> 	manoj
> -- 
>  "It's not just a computer -- it's your ass." Cal Keegan

So I should refrain from sitting on my computer??

-Jim



--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: