Mark Eichin <[EMAIL PROTECTED]> writes:
> > We already do, when you run dpkg-source --build, it makes a .orig.tar.gz
> > file, a .diff.gz file, and a .dsc file.
>
> Actually (though I admit hello-source.deb is a cool hack, it's still a
> hack -- and debian has mostly gained it's superiority from
Ian Jackson <[EMAIL PROTECTED]> writes:
> I was flabbergasted last night when I saw that Jim had answered my
> 14-point `why-not' list point by point. That message was intended to
> terminate the discussion, not start one.
Sorry. Maybe it would have had more effect on me if I read it before
I h
Dave Cinege:
> In other words Bruce needs a way to justify stifiling people that
> endanger his complete domination of the Debian project.
>
> I can see no other reason for this policy as the very *RARE* times
> their is any noise on the mailing lists it has been about that.
Dave, please try not
> The discussion of the following topics has been postponed, until the new
> source package format is discussed:
>
>* source dependencies
>* new control fields (Author, Upstream-Site, etc.)
I'd like to discuss and settle on a syntax and semantic for at least
one new source control field,
Topic 15: Documentation policy
STATE: POSTPONED
INFO: The discussion about the implementation of the new documentation
policy will be started on debian-doc soon.
REF: cf. #7890, cf. #11095
-- Christ
I didn't explain in detail how to use my proposed source packaging
format in my RFC, as it was not meant to be a tutorial. Please read
the RFC before reading this tutorial.
There has been much confusion about whether or not it is possible to
use the proposed format without root priviledges.
In
Hi,
I think we may consider preserving the rationale (for this and
any other topic), if for nothing else to answer the questions that
would follow, and to prevent the manual from being a string of do's
and don'ts with no discernible reason.
The C standard used to come with the r
> Some upstream sources use a `snapshot date' instead of a real version
> number. As these `dates' are used as version id for dpkg it is useful to
> make them all use the same format. (It doesn't matter if our version
> number _looks_ different than the one from the upstream source when a date
> is
I disagree with the following part:
> If any package has a
>large number of configuration files, (like, for example, inn does),
>then a package specific subdirectory under /etc/news should be used
>(example: /etc/news/suc
[EMAIL PROTECTED] (Fabrizio Polacco) wrote on 23.10.97 in <[EMAIL PROTECTED]>:
> Bruce Perens wrote:
> >
> > We recently had some conversation on rules of discourse for the
> > mailing lists. At that time, discussion by most developers was
> > strongly against them. Only myself and two other peop
DEBIAN POLICY WEEKLY, #4 (October 23, 1997)
The following message is a list of topics related to the Debian Policy
which are currently under discussion or which will be discussed in the
near future. This summary is sent to the debian-policy mailing list
periodically by the Debian Policy Manager.
Topic 2: Serial devices
STATE: APPROVAL
The following policy has been suggested and will become official unless
someone objects: (the rationale will probably be removed since it's too
long for the policy manual)
Serial Devices
== ===
Debian uses the new standard of
(Oops, I sent this to debian-devel by mistake. I think it belongs on
debian-policy, so I'm sending it here now.)
Majoj (SuperCite undone):
> [Ian Jackson:]
> > I was flabbergasted last night when I saw that Jim had answered
> > my 14-point `why-not' list point by point. That message was
> > inte
It's all very well having `rules', but this is IMO missing the real
question.
If people on the mailing lists get to the point where they're calling
each other names then something has gone wrong. Pointing one or both
at the `rules' and banning them for a bit doesn't seem like a solution
to the pr
From: Andreas Jellinghaus <[EMAIL PROTECTED]>
> rules don't work very well, because you have no punishment, if someone
> breaks the rules.
OK. Let me restate the problem.
I want guidelines for:
1. Digesting an individual's postings.
2. Placing an individual on moderation.
On Thu, 23 Oct 1997 09:00:14 -0700, Christoph Lameter wrote:
>: I want to check for opinions one more time before abandoning them.
>: If we do that, disrespectful language will be allowed, and obscentity
>: will be allowed. Is this really what people want?
>
>No.
I want the gestpo regulating the
Christian Schwarz <[EMAIL PROTECTED]> writes:
> Topic 16: New source package format
>
> STATE: POSTPONED
>
> The discussion of the following topics has been postponed, until the new
> source package format is discussed:
>
>* source dependencies
>* new control fields (Author, Upstream-S
Topic 12: X Window Manager policy
STATE: INPUT
Joey Hess wrote on Mon, 30 Jun 1997 to debian-devel:
I maintain KDE, which includes a window manager, and I've been
wondering how
other window managers handle registering themselves in
/etc/X11/window-managers. So I took a look
[EMAIL PROTECTED] (Jim Pick) wrote on 22.10.97 in <[EMAIL PROTECTED]>:
> Funny that there has been so much negative reaction -- and nobody has
> even bothered to download the samples I put up yet. Most of the debate
> so far has just been a knee-jerk reaction to somebody trying to shake
> up the
Mark Eichin <[EMAIL PROTECTED]> writes:
> Detail: I think "installing" sources is fundamentally wrong. This is
> partly aesthetic, but that is derived from large scale systems
> experience -- there's the system, and there are the users, and
> building packages is a *user* function, not a *system*
Topic 10: Filesystem location of non-english documentation files
STATE: INPUT
Background
There was a discussion about this topic on debian-devel around Nov 96, but
without any decision. Since a lot of package already install non-english
docs, we'll have to find a solution soon.
The previous d
[EMAIL PROTECTED] (Manoj Srivastava) wrote on 23.10.97 in <[EMAIL PROTECTED]>:
> >>"Ronald" == Ronald van Loon <[EMAIL PROTECTED]> writes:
>
> Ronald> The real question is: do we want rules or do we trust that
> Ronald> everyone will behave as mature individuals.
>
> I think that past exper
Topic 4: Announcing new packages before uploading them
STATE: APPROVAL
According to current policy, every upload of a new package to the archive
has to be announced on debian-devel _before_ the package is uploaded to
the master site. However, must developers do not know this yet. That's why
it s
Topic 5: Shared configuration files for news servers
STATE: APPROVAL
The following policy has been suggested on debian-policy and will become
official unless someone objects:
News system configuration
-
All the configuration files related to the NNTP
Hi folks!
The recent discussion about the policy weekly postings did result into
several changes. I'll try to summarize the changes here.
(This mail is cross-posted to debian-policy and debian-devel. Please
send any replies to debian-policy.)
1. Policy Manual Online
---
T
Topic 8: Dates in package versions
STATE: APPROVAL
Some upstream sources use a `snapshot date' instead of a real version
number. As these `dates' are used as version id for dpkg it is useful to
make them all use the same format. (It doesn't matter if our version
number _looks_ different than the
Hi,
>>"Jim" == Jim Pick <[EMAIL PROTECTED]> writes:
Jim>
>> Now that dpkg-source is able to manage untouched pristine source
>> when it is well-behaved, this is a step backwards.
Jim> Why backwards? Maybe a horizontal step. Actually, I think it's
Jim> a bit better, since you can have multiple
Raul Miller <[EMAIL PROTECTED]> writes:
> Er.. you've not allowed much time for people to comment. I don't think
> it's fair to be disappointed.
I know, I'm sorry. It was a long day yesterday, and I got somewhat
flustered by some of the reaction I got (to several things).
I apologize for the
[EMAIL PROTECTED] (Manoj Srivastava) wrote on 23.10.97 in <[EMAIL PROTECTED]>:
> >>"Ian" == Ian Jackson <[EMAIL PROTECTED]> writes:
Ian>> I was flabbergasted last night when I saw that Jim had answered
Ian>> my 14-point `why-not' list point by point. That message was
Ian>> intended to terminate
Topic 14: Manual page inconsistencies
STATE: DISCUSSION
REF: cf. bug #12370
In order to get the manual pages registered in the whatis database it is
necessary, that the manual pages specify the correct name and section with
the `.SH' command.
At the moment, some manual pages don't have a .SH
Part of the opposition to my proposed source packaging format is
that it forces people to use dpkg, which must be run as root.
I have demonstrated in the previous tutorial that it is possible
to still use the packages in user space by using dpkg-deb --extract.
I have since discovered that it is
Topic 13: Starting daemons in the postinst scripts
STATE: DISCUSSION
The following policy has been suggested:
If a package installs a `daemon' that is usually started via an
/etc/init.d/ script, the package should query the system
administrator after the installation (in the post
Topic 1: Bash vs Bourne shell
STATE: APPROVAL
There has been a long discussion on debian-policy about which features may
be used from the default shell /bin/sh. Currently, several packages use
bash-specific features but specify "#!/bin/sh" as interpreter.
As some users want to use "ash" as "/b
On Wed, 22 Oct 1997, Santiago Vila Doncel wrote:
> -BEGIN PGP SIGNED MESSAGE-
>
> On Thu, 3 Jul 1997, Christian Schwarz wrote:
>
> > Every package that includes HTML documentation has to support the
> > "doc-base" package (which will be created soon).
>
> Which is the current status of
Topic 3: Guidelines for Motif applications
STATE: APPROVAL
The following policy has been suggested on debian-policy and will become
official unless someone objects:
Guidelines for Motif applications
-
If you package a program that requires a non-f
Topic 7: Leaving time stamps unmodified
STATE: APPROVAL
Most of our packages `touch' files in the packaging process (that is, the
modification time of the files gets reset to the current time). It would
be nice if the modification time of the upstream source would be
preserved.
For example, yo
Topic 11: UUCP-locking of devices
STATE: INPUT
REF: cf. bug #11094 and #10575
The FSSTND (as well as the FHS draft) specifies how programs have to lock
UUCP devices. Unfortunately, the locking mechanism has several flaws.
To solve this dilemma, Fabrizio Polacco built a library for device lock
On 23 Oct 1997, Kai Henningsen wrote:
> > Bruce Perens wrote:
> >
> > Disrespectful language and obscentity disqualify only those that use
> > them. Ignoring them is the right thing to do, IMO.
>
> IMO, it depends entirely on the situation. I've seen some "disrespectful
> language and obscentit
Christian Schwarz wrote:
> The following policy change has been proposed. It will become official
> unless someone objects now:
>
> Any scripts which create files in world-writable directories (i.e.
> in /tmp) have to use a mechanism which will fail if a file with
> the same name al
Topic 6: Secure maintainer scripts
STATE: APPROVAL
The following policy change has been proposed. It will become official
unless someone objects now:
Any scripts which create files in world-writable directories (i.e.
in /tmp) have to use a mechanism which will fail if a file with
STATE: INPUT
Some people said that we should (or must? :-) change `should' into `must'
in the Policy Manual in most places, even if exceptions are allowed, since
the RFC's use this wording and some people might get confused, otherwise.
Any objections?
---
Detail: I think "installing" sources is fundamentally wrong. This is
partly aesthetic, but that is derived from large scale systems
experience -- there's the system, and there are the users, and
building packages is a *user* function, not a *system* function. (The
required use of /usr/src/linux f
Topic 16: New source package format
STATE: POSTPONED
The discussion of the following topics has been postponed, until the new
source package format is discussed:
* source dependencies
* new control fields (Author, Upstream-Site, etc.)
-
[My subscription to debian-policy is on the way, but in the meantime,
please CC: any replies to me. Thanks.]
I just caught this on Christian's excellent weekly report, and I'd
like to add my 0.01 Euro.
My suggestion would be that daemons should be started up according to
the runlevel the system
Jim Pick <[EMAIL PROTECTED]> wrote:
> Funny that there has been so much negative reaction -- and nobody has
> even bothered to download the samples I put up yet. Most of the debate
> so far has just been a knee-jerk reaction to somebody trying to shake
> up the status quo. I'm quite disappointed
On Wed 22 Oct 1997, Bruce Perens wrote:
> We recently had some conversation on rules of discourse for the mailing
> lists. At that time, discussion by most developers was strongly against
> them. Only myself and two other people spoke out for them at all.
>
> I want to check for opinions one more
In article <[EMAIL PROTECTED]> you wrote:
: We recently had some conversation on rules of discourse for the mailing
: lists. At that time, discussion by most developers was strongly against
: them. Only myself and two other people spoke out for them at all.
I had the opposite impression and was wa
On Thu, 23 Oct 97 10:27 PDT, Bruce Perens wrote:
>From: Andreas Jellinghaus <[EMAIL PROTECTED]>
>> rules don't work very well, because you have no punishment, if someone
>> breaks the rules.
>
>OK. Let me restate the problem.
>
>I want guidelines for:
>
> 1. Digesting an individual's posting
[EMAIL PROTECTED] (Ian Jackson) wrote on 22.10.97 in <[EMAIL PROTECTED]>:
> I could probably produce more but I'm bored now. Can we please put
> this issue to bed ? Just because Red Hat do it doesn't mean it's a
> good idea.
In any case, I agree with every word.
MfG Kai
49 matches
Mail list logo
