On 6 May 1998, Manoj Srivastava wrote:

> Hi,
> >>"Dale" == Dale Scheetz <[EMAIL PROTECTED]> writes:
> 
> Dale> On 6 May 1998, Manoj Srivastava wrote:
> 
> Dale> During our past discusion on these issues I made direct requests
> Dale> for clarifying statements about priorities of policies. I
> Dale> specifically asked to be kept on the cc list for any discusion
> Dale> of the issues.
> 
>       I think at the moment most of the policy document, unless
>  other wise indicated, is a MUST directive. 

I KNOW that is what you believe. It is the point of view that I most
reject from any you profess to hold.

> 
> 
> Dale> Debian's policy has always been one that rejects non functional
> Dale> binary packages.
> 
>       If policy, if followed, creates broken packages, we have a
>  problem. 

Only because you insist on your "broken" view of policy.

> 
> Dale> Even you have been willing to admit that Policy
> Dale> is broader than "The Policy Statement".
> 
>       I never said that. The policy document set, (currently a
>  a set that is referenced in or pointed to by the core 3 policy
>  documents) is all that I see as policy. 
> 
So, we ignore the DFSG, pay no attention to the "Debian Manifesto", and
completely ignore anything in any of the faqs, HOWTOs, or other related
documents. Policy makes no mention of ANSI, or POSIX and may not even make
reference to the File System Standards (this one may actually be
referenced, but I haven't looked at the Policy Statement in a while and
can't be sure). Do we throw all this in the trash? NO! Of course not! Be
reasonable...

> Dale> Do you deny that it is our policy to deliver functional binary
> Dale> packages?
>       
>       I fail to see this in policy, but that is because I think most
>  people would take it as given; I understand it is a critical goal. In
>  fact, this has to be added to the policy, if people do not find it as
>  an acceptable unspoken rule.

You can't have it both ways. If it is taken "as given", then how do people
"not fine it as an acceptable unspoken rule"?

Does anyone in this group think that delivering broken executables is
either implied or stated anywhere in Debian Policy?

I suggest that your counter example is "the empty set" and quite useless.

I can think of no one (not even you ;-) who would consider delivering
broken binaries to be even mildly suggested anywhere in "The Policy of the
Debian Development Team" (which, of course, includes "The Policy
Statement").

> 
> Dale> Do you suggest that the "strip binaries" rule should
> Dale> superceed this prime directive?
> 
>       No. The strip binaries rule, if it contravenes this primary
>  directive, is quite obviously broken. You can't say "following blah
>  would break stuss, so I shall ignore it for now. However, I do not
>  see blah as wrong [even though following blah would break my
>  package]". I just don't understand this line of reasoning.
> 
Your "understanding" is based of false assumptions.

Any reasonable person would read any portion of policy similar to the
"stripped binary" rule in the same way that I do. If you wish to make it
more explicit and state clearly that stripping binaries is only desirable
if it results in functioning code, you should feel free to work within the
policy group and change the document to be clearer.

I'm only going to say this once more:

If you think it's broken, YOU fix it.

In any case, I have no interest in hearing about how broken you think it
is. I understand your broken attitude, but seem completely unable to mend
it. As you seem unswayable by "reasonable" arguments, I will cease trying.

Later,

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz                   Phone:   1 (850) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  [EMAIL PROTECTED]     Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to