Re: debian-devel-digest Digest V98 #69
Hi,
>>"adavis" == adavis <adavis@netpci.com> writes:
adavis> Is the wool being pulled over my eyes?
>> From: Manoj Srivastava <srivasta@datasync.com> You break Debian
>> policy on your machine (as is your right), then Debian is no longer
>> responsible for support.
adavis> The point, for me, would not be whether one would be breaking
adavis> "Debian policy," but rather that Debian policy becomes a whole
adavis> new concept, disparate in some sense from the way linux has
adavis> 'traditionally' done things. Why is this necessary?
*Groan*. Have you not being paying attention? I have explained
this over and over on this list; the technical reasons for Debian's
behaviour. Please look at the Archives.
Yes, Debian is different. It has a package management
sytem. Different part of Debian work with each other. There are
asumptions part of the distribution make about itself, and because of
this set of co-operating asumptions, or rules, or policy, Debian is
better integrated than most Linux distributions I have seen.
We often do not do things the "standard" way. Like when we
started including /usr/include/{linux,asm} directories instead of
having symlinks. It is different. And was acknowledged to be
technically superior.
Again, we are making changes that shall not gbe reflected in
other distributions. I think we are making the technically superior
choice. But we shall be different again.
One of the set of rules we follow is the File system
standard. It helps us make things like, say, the menu system, or the
web servers, more effective.
adavis> "Standards"? What is standard about not being able to unpack
adavis> a plain vanilla source heirarchy and have it work as expected?
adavis> What is standard about a distribution forking off with its own
adavis> series of kludges? Is it a standard to type "debian.rules" or
adavis> whatever instead of "make"? You've bent, twisted, and warped
adavis> the meaning of the word standard and shoehorned yourself into
adavis> this new revised definition.
As I said, the standard is the File system standard.
You can't expect to unpack the kernel sources just anywhere
and not have things break. It seems to me you are unfamiliar with the
Linux Filesytem standards, the concept of systems integration, and
standards conformance.
You also seem to dislike Debian. There is a perfectly nice
distribution produced by Red hat, which may be more to your liking.
They have their own way of doing things (in your lexicon: Kludges),
but then there is always slackware.
adavis> Would it take too much skill or subtlety to build the system
adavis> such that it would not break if one choses to install his own
adavis> kernel in the way that has been done since before debian came
adavis> into existence? What do you prove by demonstrating that it
adavis> might be just as good, even better, to do it another way? (If
adavis> not a sense of self-satisfaction?)
We are striving for technical excellence. That's what we are
moving towards when we " prove by demonstrating that it might be just
as good, even better, to do it another way".
Ever since kernel packages have existed, they have manipulated
/usr/src/linux.
adavis> Most important, what harm would come of doing things in a way
adavis> that would make sense to any linux user, and not just the well
adavis> initiated debian freak?
Freak, is it? We descend to name calling?
Doing it the old way makes it harder for the package
management system to track the current set of headers/sources
installed, and harder for packages to declare dependencies.
adavis> I think if you cannot answer this, you are on an ego trip.
adavis> Reminds me of how VMS has its own instructions to compile
adavis> packages for most software.
Actually, VMS is a damn fine OS (better in a lot of ways than
UNIX). Ok, so I am on an ego trip. What have you done for the
distribution lately?
adavis> (Your answer to the last question will be taken into
adavis> consideration as I mull over whether to remain with this
adavis> distribution, that I have been using exclusively for perhaps
adavis> three years, perhaps longer.)
Please, for my sanity, do leave. If the last three paragraphs
are an example of your contribution, I think we shall be better
off. Really.
adavis> When I am told that if I follow the instructions that come
adavis> with the kernel I am breaking "debian policy," then I see that
adavis> certain luminaries have come to represent an alternative, and
adavis> CERTAINLY NOT A(n implicit) STANDARD. Maybe the reason I have
adavis> been almost always unable to compile a new 2.1.XX kernel is
adavis> that I have broken "Debian Policy" without ever really
adavis> understanding it. How are you going to get the news out to new
adavis> users that there is a different way to compile kernels than in
adavis> the normal linux FAQ's, and it's (so it is argued) better?
I run 2.1.XX kernel too, while still managing to conform to
policy. Who are the luminares you refer to? You have a point about
publicizing this.
adavis> Flame me if you will; I don't care any more---I'll probably be
adavis> looking for a new linux distribution soon. I have read
adavis> several of your explanations as to why your way is better.
adavis> I'm not convinced.
Sorry, I did the best I could. But I suspect you have litttle
knowledge of systems integration in general, anf the debian package
system in particular, to understand the merits of the situation. If
you have an alternative solution that addresses the needs of the
package management system, and the libc maintainer, which works just
as well for novices as experts, feel free to send in a proposal. I'll
be waiting.
adavis> (Apologies for the "bandwidth".)
adavis> I've really been trying. I picked up books on C so I could
adavis> compile packages I needed, and I've had to roll my own many
adavis> times. Early instructions for compiling the kernel, in the
adavis> halcyon days of the LDP, if followed to the letter, worked,
adavis> and it didn't depend upon which distribution you had
adavis> installed. If it did, you had a pathological distribution. I
adavis> fear that is what may be happening here. I expect flames,
adavis> cause this is a holy icon to many, but I, of the "preset
adavis> misguided preconceptions," who, I am sorry to say, have never
adavis> contributed anything to debian, have reached a borderline I am
adavis> unwilling to cross. It's something I feel I ought to express,
adavis> before I (probably) move along. I've never been so close to
adavis> jumping ship. Then it won't bother me anymore what kind of
adavis> fantastic innovations you come up with.
Amen.
manoj
--
"Griswold v. Connecticut first established and guaranteed the `right
of privacy' in the conjugal act. Sexual love, however, in a most
profound way is anything but `private.' Its very purpose is to break
the bonds of privacy by physical consummation of an unreserved gift
of self. The contraceptive, however, denies the meaning of marital
love by falsifying its bodily expression. Love is no longer
unreserved; something is held back. `I cannot love all of you,' the
contraceptive says, `because I cannot love all that might be created
by you.'" Edmund Miller, Anti-Abortion Commentator, Fidelity
magazine, 10/89, as quoted in "The Far Right, Speaking For
Themselves," a Planned Parenthood pamphlet
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: