Bug#1078505: developers-reference: document corner case of debian version and rational

that ~deb sorts later than ~bpo, as that updates a backport to a stable / oldstable / oldoldstable update. But that was sheer luck. This is not true for ~pre, but would work for ~~pre or ~~~~whatever... -- Henrique de Moraes Holschuh

Re: Bug#991533: lintian: please forget about required-field Standards-Version for udeb packages

n. It would be enough to add to lintian a CLI option to force a standards-version to use as baseline, hopefully? Assuming it doesn't have one yet, which it might very well have... -- Henrique de Moraes Holschuh

Bug#913659: Document that not all bugs are policy violations

On Fri, 16 Nov 2018, Sean Whitton wrote: > On Fri 16 Nov 2018 at 12:22PM -0200, Henrique de Moraes Holschuh wrote: > > How about also adding one that makes it clear that in *Debian*, policy > > follows practice, and not the other way around (which should also > > require seco

Bug#913659: Document that not all bugs are policy violations

On Tue, 13 Nov 2018, Ian Jackson wrote: > Package: debian-policy > Version: 4.2.1.4 > > The discussion in #913572 is just another instance of the following > antipattern: > >Submitter: program X does strange thing Y which is undesirable >Maintainer: Y is not against policy > > I sugge

Re: debian/upstream/signing-key.asc in policy 4.1.0

On Wed, 23 Aug 2017, Russ Allbery wrote: > Note that this Policy language is carefully written to make it perfectly > fine for uscan to support all the things it currently supports, since it > only talks about what Policy recommends the maintainer does. So don't > feel any obligation to change wha

Bug#810381: debian-policy: Update wording of 5.6.26 VCS-* fields to reflect the need for security

On Thu, 24 Aug 2017, Sean Whitton wrote: > Seconded, but I think the integrity protection is a more important > reason to avoid the git protocol or http, so if we can come up with a > further change to reflect that it would be better. Attacking the integrity of the messages in transit requires act

Re: Upstream Tarball Signature Files

On Mon, 14 Aug 2017, Russ Allbery wrote: > Henrique de Moraes Holschuh writes: > > On Sun, 13 Aug 2017, Russ Allbery wrote: > >> it can't just move the file -- it has to ASCII-armor it. But still, I > >> think that's the right thing for the tools to do,

Re: Upstream Tarball Signature Files

On Sun, 13 Aug 2017, Russ Allbery wrote: > it can't just move the file -- it has to ASCII-armor it. But still, I > think that's the right thing for the tools to do, not add another file. > (The ASCII format is completely equivalent to the binary format; the > conversion shouldn't lose or change an

Bug#865713: Please Start UTF-8 debian-policy Text Files with UTF-8 Signature

On Sat, 24 Jun 2017, Russ Allbery wrote: > Russ Allbery writes: > > I did a bit more research, and apparently this approach has become more > > blessed again. I'm glad I looked it up! As of Unicode 5.0, the ... > Okay, I experimented with this, but unfortunately less displays the BOM at > the

Bug#865367: developers-reference: section 5.5.1: explicitly mention that stable and oldstable uploads must use release codename

Package: developers-reference Version: 3.4.18 Severity: normal Section 5.5.1 seems to imply uploads to stable and oldstable should target "stable" or "oldstable" in the distribution field of the changelog entry, which is incorrect. Please add explicit text to section 5.5.1, directing uploaders to

Bug#835520: [PATCH v2 11/11] Drop entire section 9.4 Console messages from init.d scripts

g maintainers to follow the relevant sections of the LSB? -- Henrique de Moraes Holschuh

Bug#844431: Packages should be reproducible

On Tue, 15 Nov 2016, Chris Lamb wrote: > [As a mild suggestion to streamline this; we should probably come to some > consensus on principle of this addition to Policy first and only then > move to the more difficult topic of defining exactly what reproducibility > means in a technical sense.] I do

Bug#823584: [PATCH] Correct top-level directory name in repackaged tarballs

On Fri, 06 May 2016, Tormod Volden wrote: > PS. I didn't think about it initially, but I guess "NACK" means > "thanks for your patch and your interest in the developer reference, > but I don't think this is the best solution." That's pretty much correct, yes. NACK in this context implies that wha

Re: Bug#802501: init script failures during postinst and related scripts

cal mail delivery/routing, etc). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique de Moraes Holschuh

Re: Bug#801065: Section 6.4 - discourage failing install or upgrade when service fails to start

ion. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique de Moraes Holschuh

Bug#798714: debian-policy: Please explicitly recommend punctuation between the year, month and day components of date based version numbers

On Fri, 11 Sep 2015, Axel Beckert wrote: > To demonstrate my point, please sort the following version numbers in > your head: > > * 20110111.0 > * 2010.1 > * 2011.2 These are rather bad, as you might need to use epochs. In fact, they go against documented current best practice due to a l

Re: Bug#761219: debian-policy: document versioned Provides

On Fri, Mar 27, 2015, at 08:41, Niko Tyni wrote: > On Fri, Mar 13, 2015 at 05:38:39PM -0300, Henrique de Moraes Holschuh > wrote: > > On Fri, 13 Mar 2015, David Prévot wrote: > > > On Thu, Sep 11, 2014 at 09:57:57PM +0300, Niko Tyni wrote: > > > > dpkg 1.17.11 a

Bug#761219: debian-policy: document versioned Provides

On Fri, 13 Mar 2015, David Prévot wrote: > On Thu, Sep 11, 2014 at 09:57:57PM +0300, Niko Tyni wrote: > > dpkg 1.17.11 and apt 1.0.7 recently implemented support for versioned > > provides. > […] > > This clearly needs an update. No proposed wording yet, sorry. > > Here is a simple one, stripping

Re: Bug#770016: Clarify network access for building packages in main

uired target must not attempt network >access. > > Henrique, did Lucas answers about the archive rebuild address your > objections ? Yes. We can treat exceptions as... exceptions :-) -- "One disk to rule them all, One disk to find them. One disk to bring them all and in

Bug#774384: developers-reference: soften advice to justify retirement to debian-private

On Fri, 02 Jan 2015, Cyril Brulebois wrote: > Jakub Wilk (2015-01-02): > > * Jonathan Wiltshire , 2015-01-01, 21:49: > > > -Send an gpg-signed email about why you are leaving the project to > > > -debian-private@&lists-host;. > > > +Send an gpg-signed email announcing your retirement to > > > +deb

Bug#773557: debian-policy: Avoid unsafe RPATH/RUNPATH

On Sun, 21 Dec 2014, Martin Carpenter wrote: > > "Packages are not allowed to create *and* execute libraries or executables > > with unsafe RPATH or RUNPATH at any time, not even during their build > > process." > > But actually "Package maintainers should not make or run dangerous > stuff"? Agree

Bug#773557: debian-policy: Avoid unsafe RPATH/RUNPATH

On Fri, 19 Dec 2014, Jonathan Nieder wrote: > >> 8.7 RUNPATH and RPATH > >> > >> Libraries and executables should not define RPATH or RUNPATH unless > >> absolutely necessary. > > This part seems vague to me --- if a project relies on RUNPATH but could > be modified to avoid relying on it, is toda

Bug#666726: debian-policy: Clarify if empty control fields are ollowed or not

On Sun, 23 Nov 2014, Jakub Wilk wrote: > * Henrique de Moraes Holschuh , 2014-11-23, 18:49: > >>This bug is mostly to document a check in dak. Are you > >>suggesting the check is looking at the debian/control file and > >>reject source packages with empty fields? >

Bug#666726: debian-policy: Clarify if empty control fields are ollowed or not

On Sun, 23 Nov 2014, Bill Allombert wrote: > On Mon, Nov 24, 2014 at 02:15:45AM +0900, Charles Plessy wrote: > > Le Sun, Nov 23, 2014 at 03:08:47PM -0200, Henrique de Moraes Holschuh a > > écrit : > > > On Mon, 24 Nov 2014, Charles Plessy wrote: > > > > do

Bug#770016: Clarify network access for building packages in main

On Sun, 23 Nov 2014, Bill Allombert wrote: > --- a/policy.sgml > +++ b/policy.sgml > @@ -1928,12 +1928,16 @@ zope. > impossible to auto-compile that package and also makes it hard > for other people to reproduce the same binary package, all > required targets must be non-int

Bug#666726: debian-policy: Clarify if empty control fields are ollowed or not

On Mon, 24 Nov 2014, Charles Plessy wrote: > Le Sun, Nov 23, 2014 at 03:08:47PM -0200, Henrique de Moraes Holschuh a écrit > : > > On Mon, 24 Nov 2014, Charles Plessy wrote: > > > > > > do you have examples of packages having empty fields in source package >

Bug#666726: debian-policy: Clarify if empty control fields are ollowed or not

On Mon, 24 Nov 2014, Charles Plessy wrote: > Le Sat, Nov 22, 2014 at 08:15:03AM -0200, Henrique de Moraes Holschuh a écrit > : > > Empty fields in debian/control must be valid in *source* packages. It is a > > widely used feature of the dpkg-dev suite, and it has been around f

Bug#666726: debian-policy: Clarify if empty control fields are ollowed or not

On Sun, 23 Nov 2014, Bill Allombert wrote: > Anyway, this is a second try. > > Cheers, > commit d450ce8f978bad0f3927ea055698b789055dfa3a > Author: Bill Allombert > Date: Sun Nov 23 16:16:21 2014 +0100 > > Document that empty field values are only allowed in debian/control. > > diff --git

Bug#555979: debian-policy: Symlinks pointing beyond the root of the file system

On Sun, 23 Nov 2014, Jakub Wilk wrote: > * Andrey Rahmatullin , 2014-11-22, 12:39: > >--- a/policy.sgml > >+++ b/policy.sgml > >@@ -8892,6 +8892,7 @@ fname () { > > would point to /srv/run rather than the intended > > target. > > > >+ Symbolic links must not tra

Re: Bug#666726: debian-policy: Clarify if empty control fields are ollowed or not

On Sun, 23 Nov 2014, Bill Allombert wrote: > diff --git a/policy.sgml b/policy.sgml > index 6eac491..66de529 100644 > --- a/policy.sgml > +++ b/policy.sgml > @@ -2556,13 +2556,15 @@ endif > > Package: libc6 > > the field name is Package and the field value > libc6

Bug#666726: debian-policy: Clarify if empty control fields are ollowed or not

On Sat, 22 Nov 2014, Charles Plessy wrote: > Le Fri, Nov 21, 2014 at 10:56:15AM +0100, Bill Allombert a écrit : > > What about automatically generated control files and substvar ? > > e.g. > > Depends: ${misc:Depends} > > where ${misc:Depends} resolve to the empty string ? > > > > Does dpkg-gencon

Bug#770016: Clarify network access for building packages in main

On Tue, 18 Nov 2014, Andrey Rahmatullin wrote: > On Tue, Nov 18, 2014 at 09:24:15PM +0900, Charles Plessy wrote: > > I guess that it is implicit from the defintion of contrib that follows in > > 2.2.2: > > > > The contrib archive area contains supplemental packages intended to work > > with >

Bug#758234: debian-policy: allow packages to depend on packages of lower priority

On Sat, 16 Aug 2014, Charles Plessy wrote: > Le Fri, Aug 15, 2014 at 02:22:33PM -0300, Henrique de Moraes Holschuh a écrit > : > > > Am 15.08.2014 17:47, schrieb Gerrit Pape: > > > That this rule is violated in hundreds of cases [1] clearly shows that > > > there

Re: Bug#758231: rsyslog: is priority important, depends on packages with priority extra

On Fri, 15 Aug 2014, Michael Biebl wrote: > Am 15.08.2014 17:47, schrieb Gerrit Pape: > > Package: rsyslog > > Version: 8.2.2-3 > > Severity: serious > > Justification: Policy 2.5 > > > > Hi, the current rsyslog package version in testing is priority important > > and depends on packages with prio

Bug#707851: Proposed changes on menu systems

On Sat, 25 Jan 2014, Markus Koschany wrote: > I wanted to clarify that there are also efforts to support both menu > systems and that the majority of games already integrate both. > > https://wiki.debian.org/Games/JessieReleaseGoal > > In my opinion the policy should at least mention the Debian m

Re: Is this license acceptable for non-free?

Sorry about this, I sent it to the wrong ML. Will post to debian-legal. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To U

Is this license acceptable for non-free?

** PLEASE CC: ME ON REPLIES ** The new license for AMD microcode updates seems to be quite obnoxious. Is it acceptable for non-free? The full license text is reproduced below: Copyright (C) 2010-2013 Advanced Micro Devices, Inc., All rights reserved. Permission is hereby granted by Advanced M

Re: What is the use case for Policy §7.6.2 ?

Hi Josselin! On Fri, 09 Nov 2012, Henrique de Moraes Holschuh wrote: > On Fri, 09 Nov 2012, Josselin Mouette wrote: > > It looks to me that we should strictly favor the transitional package > > approach instead. Shouldn’t we entirely forbid the > > Provides/Conflicts/Replac

Re: What is the use case for Policy §7.6.2 ?

On Fri, 09 Nov 2012, Josselin Mouette wrote: > It looks to me that we should strictly favor the transitional package > approach instead. Shouldn’t we entirely forbid the > Provides/Conflicts/Replaces combination way of handling upgrades, except > for virtual packages? And instantly break even furt

Re: debian/copyright in case of multiple alternative licences

On Sat, 03 Nov 2012, Bart Martens wrote: > I understand "its copyright information and distribution license(s)" as > including all licenses, so that the user can still choose between the > alternative licenses. The packager should not choose for the user. Sometimes we have to. The source may be

Bug#397939: clean rule behavior underspecified and inconsistent with common practice

On Tue, 11 Sep 2012, Jonathan Nieder wrote: > Henrique de Moraes Holschuh wrote: > > Still, if any of you would like to do it, please wait a bit. Let's release > > Wheezy first. > > I agree that we should not upload any change along these lines to > policy in the nea

Bug#397939: clean rule behavior underspecified and inconsistent with common practice

On Tue, 11 Sep 2012, Jonathan Nieder wrote: > Bernhard R. Link wrote: > > * Jonathan Nieder [120911 05:45]: > >> The requirements in policy for > >> "debian/rules clean" are very stringent --- to avoid the > >> "unrepresentable changes" it would be enough to _remove

Bug#678607: debian-policy: "original authors" in 12.5 is unclear

On Sat, 23 Jun 2012, Jonathan Nieder wrote: > Russ Allbery wrote: > > Would one list bug-gnu-ut...@gnu.org? That's the most useful contact > > point (and we have a copyright-format field for that), but it's not in any > > real sense the "author." > > Sure it is --- it's the contact point for the

Bug#568313: Bug#673301: useless use of dpkg-statoverride

On Fri, 01 Jun 2012, Holger Levsen wrote: > > They seem to conclude 2 > > things applying on our cases : > > - dpkg-statoverride --list must be used to check if the administrator > > allows dpkg to change permissions on the file. For instance an > > administrator could set an override before th

Bug#663762: debian-policy: default for DEB_BUILD_OPTIONS=parallel=N

On Sun, 25 Mar 2012, Bill Allombert wrote: > On Sun, Mar 25, 2012 at 09:18:18AM +1030, Ron wrote: > > On Sat, Mar 17, 2012 at 04:55:19PM -0700, Russ Allbery wrote: > > > Jakub Wilk writes: > > > > > > > How should packages behave if there is no explicit "parallel=N" in > > > > DEB_BUILD_OPTIONS?

Bug#660193: developers-reference: please suggest debian/rules target name for preparing source

On Sat, 17 Mar 2012, Carsten Hey wrote: > > prebuild: > > test ! -d wafadmin > > ./waf --help >/dev/null > > mv .waf-*/wafadmin . > > rm -f .waf-*/t.bz2 > > rmdir .waf-* > > sed -n -i -e '1,/^#==>$$/ p' -e '/^#<==$$/,$$ p' waf Maybe this would work? prebuild: p

Re: [proposal] remove the requirement to compress documentation

On Mon, 20 Feb 2012, Russ Allbery wrote: > Wouter Verhelst writes: > > To be a bit more specific on this: such a tool could be implemented > > fairly trivially with a dpkg trigger. Just register a trigger that > > triggers on any file under /usr/share/doc, and have it call gzip --best > > on the f

Bug#660193: developers-reference: please suggest debian/rules target name for preparing source

On Fri, 17 Feb 2012, Carsten Hey wrote: > > > The package debianutils already uses such a target and uses 'prebuild' > > > as name. The developers reference could adopt this name. > > > > How would this relate to Policy 4.14 - debian/README.source? > > In general, debian/README.source does not co

Bug#620870: debian-policy: Please add /run as FHS exception

On Wed, 15 Jun 2011, Michael Biebl wrote: > At the current state, I'm not for adding /run/shm to debian-policy. > If we can get wider acceptance of this feature (cross-distro), then my > position > on this might change. Atm this looks like a Debian-only feature with no real > use-case why we need

Bug#646235: developers-reference: Please keep this package up-to-date in stable

Package: developers-reference Version: 3.4.4 Severity: wishlist Updates to developers-reference have no regression risk, and unlike debian-policy, whatever it contained at the time of a stable release is of little relevance: one really should base his work and interaction with the Debian project o

Bug#621833: What about userdel?

On Sun, 29 May 2011, Nicholas Bamber wrote: > I am managing a package that does 'userdel' in a purge. It removes the > home directory as that contains config files. I am a bit concerned about I've seen that cause data loss. You must make sure the homedir is exactly as you set it when you created

Re: [PATCH] Specify policy for use of revision IDs in version numbers

On Sun, 01 May 2011, Bill Allombert wrote: > On Sat, Apr 30, 2011 at 09:00:14PM -0700, Russ Allbery wrote: > > So the reason for imposing a length restriction on version numbers in > > particular is due to the UI display of aptitude? I'm a bit dubious that > > this is a good justification for a Po

Re: [PATCH] Specify policy for use of revision IDs in version numbers

On Mon, 02 May 2011, Charles Plessy wrote: > Le Sun, May 01, 2011 at 09:42:17AM -0300, Henrique de Moraes Holschuh a écrit > : > > No, but I'd like to have a MUST rule that says that you MUST specify the > > full repository and commit identification data in the 'new u

Bug#624586: Bug#618885: sasl2-bin: unowned files after purge (policy 6.8, 10.8)

On Sun, 01 May 2011, Henrique de Moraes Holschuh wrote: > On Sat, 30 Apr 2011, Russ Allbery wrote: > > Steve Langasek writes: > > > I don't think that /etc/shadow qualifies as a "configuration file", > > > either; I would call it "variable state i

Bug#624586: Bug#618885: sasl2-bin: unowned files after purge (policy 6.8, 10.8)

On Sat, 30 Apr 2011, Russ Allbery wrote: > Steve Langasek writes: > > I don't think that /etc/shadow qualifies as a "configuration file", > > either; I would call it "variable state information" (→ /var/lib), but > > it lives in /etc because a) it has to be on the root filesystem, b) > > that's wh

Re: [PATCH] Specify policy for use of revision IDs in version numbers

On Sat, 30 Apr 2011, Russ Allbery wrote: > Osamu Aoki writes: > > This is another topic. I do not think everyone agreed yet to a > > particular set of numbers. The more I looked into this issue, I think > > followings are the possible numbers: No, but I'd like to have a MUST rule that says that

Bug#587377: debian-policy: Decide on arbitrary file/path names limit

On Wed, 02 Mar 2011, Sean Finney wrote: > Having a warning in lintian for arbitrarily long (perhaps >= 256) > filenames is totally reasonable i'd say, but there's no reason to Most (all?) filesystems commonly used in Debian systems will limit you to somewhere close to 254 characters per filename (

Bug#604990: clarify man page dates policy

On Fri, 26 Nov 2010, jida...@jidanni.org wrote: > The Debian Policy Manual should state what the preferred date on manual > pages should be, or wishes upstream would make it. There is no need. This is documented in man-pages(7). It is the date the manpage was last revised. > Also mention if Deb

Bug#491318: init scripts "should" support start/stop/restart/force-reload - why not "must"?

On Fri, 11 Sep 2009, Manoj Srivastava wrote: > Looking at the bug report, it seems like we agree that the > current policy is correct, and the should should not be changed to a > must? In that case, can we just close this report? Alternatively, the proposal should be clarified to mentio

Re: Init script verbosity

On Sun, 06 Sep 2009, Magnus Holmgren wrote: > /etc/init.d/skeleton is mentioned in section 9.3.5 as an example to base init > scripts on. As you may know, it suppresses the calls to log_daemon_msg > ("Starting $DESC: $NAME") and log_end_msg ("." or " failed!") during start > and > stop if $VERB

Bug#513955: [Pkg-sysvinit-devel] Bug#339955: Bug#513955: debian-policy: do not require /etc/init.d/*.sh scripts to be sourced

On Fri, 13 Feb 2009, Russ Allbery wrote: > I went to write the patch for this, but I paused when I saw that the other > part of this sentence (explicitly running such scripts with sh at other > run levels) is implemented. The current /etc/init.d/rc runs the script > directly if it doesn't end in .

Re: Clarify what "sensible behaviour" is for init scripts

On Fri, 04 Jul 2008, Raphael Hertzog wrote: > Here's a try (against current master branch): > diff --git a/policy.sgml b/policy.sgml > index c9bd84f..772afce 100644 > --- a/policy.sgml > +++ b/policy.sgml > @@ -5946,9 +5946,11 @@ rmdir /usr/local/share/emacs 2>/dev/null || true > The init

Bug#397939: Lintian: outdated-autotools-helper-file

On Mon, 11 Feb 2008, Kapil Hari Paranjape wrote: > Note that if the upstream's auto-generated files are deleted during > the clean target, then the source *must* be re-packaged to avoid > needless clutter in the .diff.gz which is of a "negative" nature. Not so. Deletions are ignored. Ever tried

Re: deluser on purge (was: Piuparts testing status update)

On Tue, 12 Dec 2006, Michelle Konzack wrote: > Am 2006-11-27 13:02:18, schrieb Michael Stone: > > On Mon, Nov 27, 2006 at 05:33:25PM +0100, Michelle Konzack wrote: > > >And HOW can I get UID's >=65536 to work? > > > > > >I have already tried it in my /etc/passwd and > > >/etc/group but it gives to

Re: How thorough must the clean target be?

On Thu, 05 Oct 2006, Bill Allombert wrote: > \usepackage[shameless]{plug} > \begin{plug} > I have proposed a (IMVHO) better solution to the > config.sub/config.guess problem see > > \end{plug} You know, I'd have appreciated getting tha

Re: binNMU safe and ${binary:Version} or ${source:Version}

On Thu, 14 Sep 2006, Steve Langasek wrote: > > The BIG problem is how to get the next-version. Say you have version > > 1.2-3. A binNMU would be 1.2-3+b1, a security release would be > > 1.2-3etch1 (unless there was a binNMU). > > In the Great Scheme, these were supposed to become 1.2-3+etch1 inst

Re: dak now supports ~ in version numbers

On Wed, 09 Aug 2006, Manoj Srivastava wrote: > > Policy documents reality, so if now the reality is that ~ is > > supported and its use is encouraged, then yes, policy should be > > changed ASAP. > > No. Policy documents what is correct, not just any old broken > thing that is currently b

Re: dak now supports ~ in version numbers

On Wed, 09 Aug 2006, sean finney wrote: > > > Thanks to the work of our DPL Anthony "aj" Towns (and all the other > > > people who have worked on this without my knowledge), I am happy to > > > announce that dak, our archive management software, finally supports > > > the use of the tilde ('~') in

Bug#152955: debian-policy: Clarify force-reload, be LSB-compliant in doing so.

On Mon, 10 Jul 2006, Sven Mueller wrote: > I think we need something like a "policy to be", i.e. some document > which shows which changes _should_ go into the policy document as soon > as packages are fixed accordingly. Something that results in an We can have a "ongoing tasks" page in the wiki,

Bug#152955: debian-policy: Clarify force-reload, be LSB-compliant in doing so.

On Fri, 07 Jul 2006, Sven Mueller wrote: > Package: debian-policy > Version: 3.7.2.1 > Followup-For: Bug #152955 > > According to LSB 3.1 (see [1]), force-reload should only restart the > service if it is already running. Therefore I suggest applying the This is directly against what we have impl

Re: Bug#370471: use of "invoke-rc.d $PACKAGE stop || exit $?" in prerm scripts

On Mon, 26 Jun 2006, Gerrit Pape wrote: > Instead of writing their pid to a file, daemons could maintain a fifo > and read (one-byte) commands from there; if there's no reader on the > fifo, the daemon isn't running and nothing bad happens. Agreed. > Or better yet, instead of duplicating such cod

Re: Bug#370471: use of "invoke-rc.d $PACKAGE stop || exit $?" in prerm scripts

On Wed, 21 Jun 2006, Gerrit Pape wrote: > On Mon, Jun 05, 2006 at 03:36:30PM +0300, Lars Wirzenius wrote: > > The policy manual says (9.3.2 Writing the scripts): > > > > The init.d scripts should ensure that they will behave sensibly > > if invoked with start when the service is al

Bug#370471: use of "invoke-rc.d $PACKAGE stop || exit $?" in prerm scripts

On Mon, 05 Jun 2006, Lars Wirzenius wrote: > The policy manual says (9.3.2 Writing the scripts): > > The init.d scripts should ensure that they will behave sensibly > if invoked with start when the service is already running, or > with stop when it isn't, and that they don'

Re: Make use of invoke-rc.d, if available, mandatory?

On Mon, 03 Apr 2006, Lars Wirzenius wrote: > Current policy states in section 9.3.3.2 ("Running initscripts") the > following: "The use of invoke-rc.d to invoke the /etc/init.d/* > initscripts is strongly recommended[51], instead of calling them > directly." > > Footnote 51 further says: "In the

Re: [EMAIL PROTECTED]: init scripts and the "reload" target]

On Mon, 23 Jan 2006, sean finney wrote: > is my interpretation of this correct, or am i over-analyzing things? As I have already told you, yes, you ARE correct, and yes, anyone restarting stuff in the reload target has a bug in their packages. -- "One disk to rule them all, One disk to find th

Bug#346598: init script stop example should use --oknodo

On Sun, 08 Jan 2006, Matt Kraai wrote: > According to the LSB Core Specification 3.1, init scripts should > consider running stop on a service already stopped or not running > successful, but the example in policy does not behave this way because > it does not pass --oknodo to start-stop-daemon in

Re: dependencies on makedev

On Thu, 29 Dec 2005, Marco d'Itri wrote: > These packages have already been fixed: > rng-tools Huh? rng-tools certainly takes benefit of MAKEDEV. It doesn't bork if MAKEDEV has disappeared, though. Is that what you mean? rng-tools postinst does this: (cd /dev && ./MAKEDEV hwrandom || ./MAKEDEV

Re: [Proposal] binaries must not have rpath outside /usr/lib//

On Fri, 02 Dec 2005, Ian Jackson wrote: > A sensible way to arrange for this to work might be for > /usr/bin/frobnicate's rpath to specify /usr/lib/frobnicate/modules. > That way frobnicate can load `frictive' without having to specify the > path. Hmm... (reads ELF 1.2). Oh drat, DT_RPATH is a col

Re: [Proposal] binaries must not have rpath outside /usr/lib//

On Fri, 02 Dec 2005, Ian Jackson wrote: > > Indeed, rpath is only acceptable for: > > 1. dynamically loaded modules/plugins > > 2. libraries that must live outside of ld.so directories > > And these things might reasonably be searched for in > /usr/local/lib/foo as well as /usr/lib/foo. rpath

Re: [Proposal] binaries must not have rpath outside /usr/lib//

On Wed, 30 Nov 2005, Ian Jackson wrote: > Just as one example, a program might reasonably have an rpath in > /usr/local/lib//. And there might be other reasons why Not in Debian, it doesn't. Since policy is about Debian *packages*, and Debian cannot ship much more than empty dirs under /usr/loca

Re: [Proposal] binaries must not have rpath outside /usr/lib//

On Mon, 28 Nov 2005, Bill Allombert wrote: > So I would propose for policy explicitly forbid 2) and 3). Agreed. In particular, 3) is a MUST NOT if I ever seen one. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of

Re: [Pkg-sysvinit-devel] Bug#339955: sysv-rc: /etc/init.d/*.sh should be sourced in runlevel S

On Sat, 19 Nov 2005, Petter Reinholdtsen wrote: > What a strange thing for policy to specify. :) On the contrary. > This will make it impossible to speed up the rcS.d boot by running > scripts in parallel. It does not sound sensible to me. rc.S scripts have always had the capability of setting

Re: Add Debian revision number standards to policy?

On Thu, 03 Nov 2005, Steve Langasek wrote: > On Thu, Nov 03, 2005 at 06:45:32PM +0100, Kurt Roeckx wrote: > > If I number it 1.2-0.1, it would mean it's no longer a native > > package. Does that mean I should split it in an .orig.tar.gz and > > a diff? > > On the contrary; Policy does not say tha

Re: Add Debian revision number standards to policy?

On Thu, 03 Nov 2005, Kurt Roeckx wrote: > How about numbering for native packages? People seem to be > disagreeing alot on how to do that: I won't touch that one. IMHO people can number diff-less packages whichever way they want to. > Should I add a debian reversion or not? Say the version is

Re: Add Debian revision number standards to policy?

On Thu, 03 Nov 2005, Julian Gilbey wrote: > On Thu, Nov 03, 2005 at 01:01:22AM -0200, Henrique de Moraes Holschuh wrote: > > On Tue, 01 Nov 2005, Nathanael Nerode wrote: > > > I was surprised to discover that the standard rules for Debian > > > revision numbers > >

Re: Add Debian revision number standards to policy?

On Tue, 01 Nov 2005, Nathanael Nerode wrote: > I was surprised to discover that the standard rules for Debian > revision numbers > (maintainer revisions contain no dots; > source NMUs contain one dots; > binary NMUs contain two) > are not in Policy, but only in the Developer's Reference. They ar

Re: Section 6.3 should reference 3.10.1 (was: It is 23:53, do you know whether your package (un)installs cleanly?)

On Sun, 04 Sep 2005, Marc 'HE' Brockschmidt wrote: > Lars Wirzenius <[EMAIL PROTECTED]> writes: > > * Some packages still don't use debconf for prompting, and > > instead do silly stuff that assumed it is OK to read and > > write /dev/tty. > > Actually, the policy expli

Re: libxine1 creates /u/s/d/xine/

On Fri, 06 May 2005, Joerg Sommer wrote: > Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: > > On Sun, 03 Apr 2005, Bill Allombert wrote: > >> For the record: > >> $ dpkg -L libxine1|grep /usr/share/doc > >> /usr/share/doc/xine > > [...] >

Re: Policy for devfs support

On Sat, 23 Apr 2005, Russell Coker wrote: > On Friday 22 April 2005 21:28, Henrique de Moraes Holschuh <[EMAIL > PROTECTED]> > wrote: > > > SE Linux also has a list of device names for initially labelling a file > > > system. Neither devfs nor devfs dev

Re: Policy for devfs support

On Fri, 22 Apr 2005, Russell Coker wrote: > On Sunday 27 March 2005 00:26, Roger Leigh <[EMAIL PROTECTED]> > wrote: > > Is there a project-wide policy for support for devfs (and devfs-style, > > e.g. udev devfs.rules) device naming? > > The SE Linux kernel code doesn't and won't support devfs. D

Re: Bug#303596: Emacs installation fails on vfat fs

On Fri, 08 Apr 2005, Rob Browning wrote: > Before I'd be willing to change this, I'd need to hear from > debian-policy that such a change would be acceptable. Current policy Debian requires a *POSIX* system to work. VFAT ain't POSIX, so no dice. There is no need to get a policy stick for this, it

Re: libxine1 creates /u/s/d/xine/

On Sun, 03 Apr 2005, Bill Allombert wrote: > For the record: > $ dpkg -L libxine1|grep /usr/share/doc > /usr/share/doc/xine [...] > Given the binary package 'xine' does not exist currently, I think this > is a policy violation due to namespace breakage. Agreed. The directory would have to be name

Re: Policy for devfs support

On Sat, 26 Mar 2005, Roger Leigh wrote: > Is there a project-wide policy for support for devfs (and devfs-style, > e.g. udev devfs.rules) device naming? Do it if you can. It is not mandated anywhere, but it is clearly a very good idea. We should even make it a *may* in policy to stress this, I su

Re: watch file in policy

On Mon, 14 Feb 2005, Adam Heath wrote: > On Sat, 12 Feb 2005, Bluefuture wrote: > > 3. submit with a wishlist (tag patch) bug to BTS. > > These things shouldn't be filed as bugs, when there are so many. Make a It is not an one-go mass-bug filling, since he has to review every watch file anyway.

Re: watch file in policy

On Sat, 12 Feb 2005, Bluefuture wrote: > This issue freeze the dehs information system in a quite unusable satus. No, it doesn't. IMHO, DEHS is useful even if it has not too many packages registered. > 1. get automatic generated watch file from dehs > 2. check itand > 3. submit with a wishlist

Bug#268377: (fwd) Re: Bug#268377: Bug#291939: Support for arch aliases (Was: Split System/Cpu for architecture handling)

Drat, reply to list was not what I had to do. Sorry about this. - Forwarded message from Henrique de Moraes Holschuh <[EMAIL PROTECTED]> - On Mon, 24 Jan 2005, Guillem Jover wrote: > The idea is to introduce architecture aliases, they will only take [...] > I've a ad

Re: Bug#268377: Bug#291939: Support for arch aliases (Was: Split System/Cpu for architecture handling)

On Mon, 24 Jan 2005, Guillem Jover wrote: > The idea is to introduce architecture aliases, they will only take [...] > I've a added as well a new option (-n normalize) to dpkg-architecture > so Maintainers can use it to get the alias expansions. Try it to see > the results. The (only) problem I c

Re: Bug#291631: cmp/diff/etc. lack PT_GNU_STACK header

On Mon, 24 Jan 2005, Santiago Vila wrote: > > Since diffutils was uploaded the 19/01/2005 I see no explanation why > > it has the problem unless the maintainer built it on top of woody. > > (The gcc changes is dated Sun, 9 Nov 2003). > > That's the correct explanation, yes. It has never been a bu

Bug#291177: [PROPOSAL] Policy for user/groups creation/removal in package maintainer scripts

On Wed, 19 Jan 2005, Javier Fernández-Sanguino Peña wrote: > On Wed, Jan 19, 2005 at 09:54:50AM -0200, Henrique de Moraes Holschuh wrote: > > On Wed, 19 Jan 2005, Javier Fernández-Sanguino Peña wrote: > > > There is currently no policy on how should per-package users be

Bug#291177: [PROPOSAL] Policy for user/groups creation/removal in package maintainer scripts

On Wed, 19 Jan 2005, Javier Fernández-Sanguino Peña wrote: > There is currently no policy on how should per-package users be created and > removed. Eeven though the 'UID and GID classes' sections determines that > packages _should_ use adduser --system in some occasions it doesn't Make it *must

  1   2   >