On 14 Jan 1998 [EMAIL PROTECTED] wrote:
> > Is it necessary that we're allowed to change the content of documents in
> > main? I would like to package the standard documents from W3, but they
> > don't allow to change the content. And this makes sense, because this
> > documents are standard
> On 14 Jan, joost witteveen wrote:
> >>
> >> Debian Policy Weekly issue #5 :
> >>
> >>runtime pkg:shared lib stripped with --strip-unneeded
> >>develop pkg:static lib stripped with --strip-debug
> >>debug pkg: static lib unstripped
> >
> > I may be _way_ wro
On 14 Jan, joost witteveen wrote:
>>
>> Debian Policy Weekly issue #5 :
>>
>>runtime pkg:shared lib stripped with --strip-unneeded
>>develop pkg:static lib stripped with --strip-debug
>>debug pkg: static lib unstripped
>
> I may be _way_ wrong here, but it se
> Is it necessary that we're allowed to change the content of documents in
> main? I would like to package the standard documents from W3, but they
> don't allow to change the content. And this makes sense, because this
> documents are standards.
Can you point me to the license statement? I
Moin Moin!
Is it necessary that we're allowed to change the content of documents in
main? I would like to package the standard documents from W3, but they
don't allow to change the content. And this makes sense, because this
documents are standards.
Maybe we should change the policy for docu
-BEGIN PGP SIGNED MESSAGE-
I agree that the proposed text is better than nothing, but it is still too
weak.
Even if we keep upstream source numbers untouched, it would be a good
thing to encourage upstream authors to use -MM-DD because it
is an ISO standard for dates.
Therefore we sh
> [EMAIL PROTECTED] (Christian Schwarz) wrote on 13.01.98 in <[EMAIL
> PROTECTED]>:
>
> > To prevent having to use epochs for every new upstream version,
> > the version number should be changed to the following format in
> > such cases: `96-05-01', `96-12-24', and starting with t
[EMAIL PROTECTED] (Christian Schwarz) wrote on 13.01.98 in <[EMAIL PROTECTED]>:
> To prevent having to use epochs for every new upstream version,
> the version number should be changed to the following format in
> such cases: `96-05-01', `96-12-24', and starting with the year
>
[EMAIL PROTECTED] (Christian Schwarz) wrote on 13.01.98 in <[EMAIL PROTECTED]>:
> The current policy does not allow packages to touch /etc/crontab anymore.
> This is because we don't allow packages to modify other packages
> configuration files.
We should also correct the policy to say that _no_
[EMAIL PROTECTED] (Christian Schwarz) wrote on 13.01.98 in <[EMAIL PROTECTED]>:
>* (As current policy says) the person doing the non-maintainer upload
> should send a bug report to the bug tracking system explaining his/her
> changes. This is extremly important so that the usual mai
[EMAIL PROTECTED] (Christian Schwarz) wrote on 13.01.98 in <[EMAIL PROTECTED]>:
> So, if a package upload fixes some bugs, the maintainer should include
> some tags in the debian/changelog file that use the following syntax
> (Perl regexp syntax, case-insensitive):
>
>/
[EMAIL PROTECTED] (Christian Schwarz) wrote on 13.01.98 in <[EMAIL PROTECTED]>:
> No program may depend on environment variables to get reasonable
> defaults. (That's because these environment variables would have
> to be set in a system-wide configuration file like /etc/profile,
>
>
> [This mail is part of Debian Policy Weekly issue #5]
>
> Topic 11: Policy on stripping static libraries
>
> STATE: APPROVAL
>
> In December, we had a discussion on debian-devel about how we should treat
> static libraries WRT stripping. Currently, the policy only specifies how
> shared libr
[I'm replying to debian-policy since this is of public intrest, I think.
Hope you don't mind.]
On Wed, 14 Jan 1998, Steve Greenland wrote:
> On 14-Jan-1998 10:40:14, Christian Schwarz <[EMAIL PROTECTED]> wrote:
> >
> > No, I don't think so. Listing unsupported options in the `syntax' line
> >
On Wed, 14 Jan 1998 [EMAIL PROTECTED] wrote:
> On Tue, Jan 13, 1998 at 11:34:21PM +0100, Christian Schwarz wrote:
> > Restrict your script to POSIX features when possible so that it may
> > use /bin/sh as its interpreter. If your script works with ash, it's
> > probably POSIX compli
On Tue, Jan 13, 1998 at 07:13:31PM -0600, Steve Greenland wrote:
> No, dpkg gets this right -- it compares numerically, not textually, if
> it can:
Oh yes, I knew that really :)
I still think it would be better to use four digit years.
On Tue, Jan 13, 1998 at 11:34:21PM +0100, Christian Schwarz wrote:
> Restrict your script to POSIX features when possible so that it may
> use /bin/sh as its interpreter. If your script works with ash, it's
> probably POSIX compliant, but if you are in doubt, use /bin/bash.
I'd pref
On Wed, 14 Jan 1998, Hamish Moffatt wrote:
> On Tue, Jan 13, 1998 at 11:34:24PM +0100, Christian Schwarz wrote:
> > Each /etc/init.d script _has_ to provide the following options:
> >
> > startstarts the daemon(s)
> > stop stops the daemon(s)
> >
> >
On Wed, 14 Jan 1998, Remco Blaakmeer wrote:
[snip]
> With the policy on POSIX shells coming up, would a virtual package `sh',
> or `posix-shell', be appropriate? I think bash and ash could provide it,
> and possibly others, too (ksh? zsh?). I also think the link /bin/sh
> could be perfectly manage
On Tue, 13 Jan 1998, Steve Greenland wrote:
> On 13-Jan-1998 23:34:29, Christian Schwarz <[EMAIL PROTECTED]> wrote:
> >
> > 1. With the current proposal, bug reports are only closed for source
> > uploads. (That's important since we don't want our bugs being closed
> > several tim
[Sorry to be offtopic a bit]
"Remco" == Remco Blaakmeer <[EMAIL PROTECTED]> writes:
> I also think the
> link /bin/sh could be perfectly managed by the `alternatives'
> system, with the `smallest' shell (in terms of memory and processor
> requirements) having the highest priority.
How about "mos
"Christian" == Christian Schwarz <[EMAIL PROTECTED]> writes:
> [This mail is part of Debian Policy Weekly issue #5]
>
> Topic 10: System-wide environment variables used for program
> configuration
I agree with this Topic, but I just want to play devil's advocate a
bit.
> No program may depe
On Tue, 13 Jan 1998, Christian Schwarz wrote:
>
> [This mail is part of Debian Policy Weekly issue #5]
>
> Topic 13: New virtual packages
>
> STATE: APPROVAL
>
> The following virtual packages have been requested: `pascal-compiler' and
> `libc-dev'.
>
> Some packages like noweb need to depend
Hi,
>>"Christian" == Christian Schwarz <[EMAIL PROTECTED]> writes:
Christian> However, both FSSTND and FHS are very clearly state:
Christian> /usr/src :
Christian> Any non-local source code should be placed in this
Christian> subdirectory.
Christian> IMHO, /usr/local/src is the place for the sysa
On Tue, 13 Jan 1998, Mark Baker wrote:
> On Tue, Jan 13, 1998 at 11:34:32PM +0100, Christian Schwarz wrote:
>
> > To prevent having to use epochs for every new upstream version,
> > the version number should be changed to the following format in
> > such cases: `96-05-01', `96-12-2
On 13-Jan-1998 23:35:47, Mark Baker <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 13, 1998 at 11:34:32PM +0100, Christian Schwarz wrote:
> > To prevent having to use epochs for every new upstream version,
> > the version number should be changed to the following format in
> > such cases:
On Tue, Jan 13, 1998 at 11:34:24PM +0100, Christian Schwarz wrote:
> Each /etc/init.d script _has_ to provide the following options:
>
> startstarts the daemon(s)
> stop stops the daemon(s)
>
> restart has to stop and start the daemon(s)
>
On 13-Jan-1998 23:34:29, Christian Schwarz <[EMAIL PROTECTED]> wrote:
>
> 1. With the current proposal, bug reports are only closed for source
> uploads. (That's important since we don't want our bugs being closed
> several times, once for each architecture :-)
I'm sorry, I missed
On Tue, Jan 13, 1998 at 11:34:23PM +0100, Christian Schwarz wrote:
> Since a few packages have to register cron jobs which need to be run more
> often than `daily', the cron package has been changed to read all files in
> /etc/cron.d too and interpret these as additions to /etc/crontab. With that,
29 matches
Mail list logo
