Re: where do NEW packages go?
On Sun, May 19, 2002 at 01:51:57PM +0200, Wouter Verhelst wrote:
> The way I understand Jeroen's mails is "GNU Coding standards are the way
> to go; everything else is braindead". If that understanding is incorrect,
> then forget everything I mailed on the subject; if not, then I feel you
> (Jeroen) should implement GNU's coding standards somewhere else. Debian
> has its own "Coding Standards", and they're different from what GNU
> says. The Hurd port should implement Debian's policy wherever possible,
> and issue policy amendments through proper channels where not instead of
> saying that Debian's policy is braindead, and ignoring it.
>
> Again, this is based on what I understood from Jeroen's mails, not on
> anything else.
Well, this issue has many aspects. If you read the GNU coding standards,
then it is mostly about code, and that only applies to GNU software packages
anyway (and Debian doesn't have a coding standard at all tha specifies how
program code should look like). So let's just ignore this part.
However, the GNU coding standard also defines some things that have an
effect on the GNU system. Things like: The GNU system should not refer to
non-free (proprietary) software. Things like: The existence of /libexec,
etc.
The big question is if Debian (GNU/Hurd) can and/or should be the GNU
system. This is probably too big a question, and is not specific enough
(what does it exactly mean, to be the GNU system?) and has potential to be
loaded by emotions. Frankly, I am scared to ask this question, and I don't
see the point in asking it right now anyway. (So please let us not even
start to discuss it here.)
But the individual issues, like /libexec, can be discussed and decided upon.
They are specific, and have a value outside of the context of the GNU system.
For example, with /libexec, we will take it up with the FHS, because we
think it is the right thing to do (if we wouldn't think so, we would try to
change the GNU coding standard on this issue).
I don't agree that the Hurd should simply try to implement Debian's policy
wherever possible, and only try to change what absolutely is impossible to
implement. The process of reevaluating Debian's policy is a healthy one,
and can only lead to an even better policy. But it's not quite as bad as it
sounds, as most of Debian's policy doesn't conflict with anything we are
doing. I can't even think of an example of something that doesn't really
need to change but would be nice to have, so there probably aren't many.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: