Bug#1068220: normalize case of debian/control fields
Package: debian-policy Version: 4.6.2.1 In the process of preparing mass-NMUs for the time_t transition, I encountered a package where the scripted approach I was using failed because a package already had a 'replaces' field in debian/control, and dpkg detected the addition of a 'Replaces' field as a duplicate. Although we are accustomed to seeing a certain capitalization for fields in debian/control, I was surprised to see upon review that Debian Policy has always said that the field names are case-insensitive. While it may make sense for dpkg to be permissive in this regard, I don't think it makes sense for Debian to allow it, as it unnecessarily makes parsing of this file more difficult for little value. I therefore propose that we change Debian policy 5.1 to standardize its case rules for debian/control field names, using the well-known spongebob casing rules. The first, third, fourth, and seventh characters in the field name are capitalized, with the second, fith, sixth, and eighth characters in lower case, then repeating for each subsequent octet of characters. As you can see, this consistency immediately gives much more readable results: SoURce: xz-utils SeCTioN: utils PrIOriTy: optional MaINtaInEr: Jonathan Nieder UpLOadErS: Mohammed Adnène Trojette BuILd-DePeNDs: debhelper-compat (= 13), dpkg-dev (>= 1.16.2), autoconf (>= 2.64~), automake, libtool (>= 2.2), gettext, autopoint | gettext (<< 0.18-1), autopoint | cvs, po4a BuILd-DePeNDs-Indep: doxygen BuILd-CoNfLIctS: automake1.4 StANdaRdS-VErsIoN: 4.6.1 VcS-brOwSeR: https://salsa.debian.org/debian/xz-utils VcS-giT: https://salsa.debian.org/debian/xz-utils HoMEpaGe: https://tukaani.org/xz/ RuLEs-ReQuIRes-rOoT: no Thanks for considering, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#801065: Documenting how to not fail postinst on service fails to start
On Mon, Feb 13, 2023 at 09:03:34AM -0500, Marvin Renich wrote: > * Steve Langasek [230212 00:03]: > > FWIW I think that it's the wrong thing to do if the "circumstances" include > > reverse-dependencies on the package which expect to interact with the > > service the package provides, as these packages may themselves do such > > interaction in the maintainer script, resulting in cascading damage. > > And the decision for whether there are reverse-dependencies on your package > > is non-local and asynchronous. > > Therefore I think it's always wrong for a package's postinst to exit 0 if: > > - it ships a service, > > - it is a new install or an upgrade on a system where the service was > >previously started successfully, and > > - the service fails to start in the postinst. > I have to strongly disagree with this. Suppose package A ships a > service, and package B depends on A and requires A's service to be > running in order for package B to be useful. If I install A and disable > its service, and then install B, I would be very disappointed if B's > postinst script failed and left B in what dpkg considers an unconfigured > state. > Succeeding the install and requiring the user to manually run some > documented configuration steps is _so_ much more user friendly than > leaving a broken package (from dpkg's POV). I intentionally disabled A, > so when I want to use B, I will take the necessary steps. I would > expect that attempting to use B without completing the configuration > would produce a useful error message. Up until now the conversation has been about the semantics of exit codes for package A's maintainer script. You are now arguing that a package *B* is not allowed to fail on install if the conditions for its full configuration have not been met. And I absolutely disagree! Your rationale that it's user-unfriendly to leave a package in an unconfigured state, if followed to its logical conclusion, applies to *any* package. We might as well not care about postinst exit codes at all! This is not hyperbolic. By imposing restrictions on the ability of packages to raise error conditions, you are forcing the propagation of erroneous system state up the dependency stack, breaking untold numbers of assumptions in the reverse-dependencies. Keeping the error handling *local* and forcing the admin to correct the error before proceeding is part of what makes Debian's system robust. On 'apt dist-upgrade', having a failing maintainer script can be problematic wrt the package manager's full state. But there is no such counterargument wrt robustness for the simple case of an 'apt install foo' failing its initial configuration because the system preconditions are not met. > Package relationships and the idea of "properly configured" have gotten > much more complex (in a relatively small set of packages) since early > Debian days. Packages whose configuration has complex requirements > should be installable without complete configuration and should be > resilient and provide good user feedback when run before being properly > set up. > I also think that such packages are the exception, rather than the rule, > and they are usually being administered by people capable of dealing > with postponing the configuration step. They are also capable of dealing with 'apt -f install'. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#801065: Documenting how to not fail postinst on service fails to start
On Wed, Feb 08, 2023 at 03:49:48PM +, Holger Levsen wrote: > On Wed, Feb 08, 2023 at 08:39:36AM -0700, Sam Hartman wrote: > > >>>>> "Holger" == Holger Levsen writes: > > Holger> I don't think there has been consent on the issue, thus I'm > > Holger> tagging it moreinfo. > > My reading of the TC and debian-devel discussion was that this was at > > least a reasonable thing for maintainers to do, > can you give pointers? > > and whether it should be done depended on the circumstances. > I do agree with that. I'm more against a general recommendation, depending > on the circumstances, it's the right thing to do. FWIW I think that it's the wrong thing to do if the "circumstances" include reverse-dependencies on the package which expect to interact with the service the package provides, as these packages may themselves do such interaction in the maintainer script, resulting in cascading damage. And the decision for whether there are reverse-dependencies on your package is non-local and asynchronous. Therefore I think it's always wrong for a package's postinst to exit 0 if: - it ships a service, - it is a new install or an upgrade on a system where the service was previously started successfully, and - the service fails to start in the postinst. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#911165: debian-policy: drop requirement to ship sysvinit init script with same name
On Wed, Oct 17, 2018 at 10:07:44AM +0200, Ansgar Burchardt wrote:
> Russ Allbery writes:
> > Until such time as we make a project-wide
> > decision to drop support for sysvinit, providing an init script for
> > straightforward daemons is part of packaging a daemon. If people are
> > unwilling to do this work, I don't believe we should accept the package in
> > Debian. In other words, I personally believe not providing an init script
> > should be an RC bug (as Policy currently indicates) given the current
> > project stance on init systems, except for the standard exception case of
> > packages that are specifically designed to only be meaningful with systemd
> > for which making them work with any other init system would require
> > significant porting (not just writing a simple equivalent init
> > script).
> That exception does not exist in Policy; there is only an exception for
> packages provided by the init implementation itself. Policy currently
> requires the "Loose coupling of init systems" option of
> https://www.debian.org/vote/2014/vote_003 as far as I can tell as
> services must be able to run under sysvinit.
> We already have several packages only shipping systemd units, including
> with socket activation (I did not check if any services cannot be
> configured to not listen on their own, but I wouldn't be surprised).
> Those with socket activation include: chasquid, cockpit-ws, erlang-base,
> hddemux, ibacm, rkt, snapd, sssd-kcm, tang, tinysshd.
I actually don't agree with this policy proposal - I think that if we are
going to support non-systemd init at all in Debian, it needs to be more than
lip service, and that means policy needs to spell out that maintainers have
a responsibility to help hold the line - but there's one package in your
list above that I have specific knowledge of. The snapd package uses socket
activation, yes, but this is an optimization and the package could equally
be started using /lib/systemd/system/snapd.service.
However, the package does not ship an init script. There would be no point.
The snapd service as implemented upstream generates and manages systemd
units, including both .service and .mount units. Making snapd work with
non-systemd init would be a non-negligible upstream porting effort.
Snapd is also not straightforwardly portable to non-Linux kernels, which
IMHO is the principle reason that Debian should continue to care about
non-systemd init at all.
Should Debian refuse to allow a package into a stable release ("RC-buggy")
whose upstream has made technology decisions that tie it to a particular
sysvinit-incompatible init system?
Again, I think the current policy language is broadly correct and don't
think it should be dropped outright. I think now that we have more
experience with systemd as default, and more examples we can point to in the
archive, it is time to think about how we should add more nuance to the
policy.
> I wouldn't be surprised to see more services require systemd's socket
> activation in the future.
> (Also, see DBus-activated services, inetd-style socket activation,
> .timer units with their associated .service; there is no need for a
> sysvinit script in these cases, but Policy requires it.)
In my mind, the intent of the current policy language is to require an init
script matching any .service units, not for .socket or .timer units.
Perhaps the text should be refined to be systemd-specific instead of
continuing to treat "alternate init systems" generically, and then call this
out?
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
Bug#850156: Please firmly deprecate vendor-specific series files [and 1 more messages]
On Wed, Aug 01, 2018 at 02:12:13AM +0200, Guillem Jover wrote: > > I'm definitely not even going to consider removal of extraction support, > > because that would break at least historic source unpacking. That's > > the price of adding these kinds of features into dpkg. > > When it comes to deprecation of the packing, see above. When I saw this > > thread I initially though that at least adding options to forbid packing > > and unpacking this kind of source would be a nice compromise, but with > > the ctte being involved I've lost any motivation for that. > > In any case I'm not even sure why dpkg is any kind of blocker for this > > at all, because acceptance into the Debian archive is controlled by > > ftp-masters, f.ex via lintian and its auto-reject list. Well, it might > > be if there's some kind of intention to try to block this even for other > > unrelated derivatives… > I'm detaching dpkg from this, I don't see anything constructive to do > out if this, TBH. > If someone wants to see dpkg changed in some way related to this, I'd > request the same thing I did to Ian a couple of years ago, gather > input from derivatives and other current users, on their reasons for > using it, or start a discussion with them on whether they'd be > satisfied with potential alternatives, etc. I will limit myself to pointing out the asymmetry of this requirement: Ubuntu as a derivative was not consulted before ubuntu.series was inflicted on us, but other derivatives who like this feature must be consulted before upstream will un-break it for Ubuntu. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#846970: Patch to document Build-Indep-Architecture field
On Fri, Jun 15, 2018 at 07:05:17PM +0100, Sean Whitton wrote: > Thank you for this analysis. > My original expectation was that the most common use of the field would > be of the form > Build-Indep-Architecture: !amd64 I can't imagine why anyone would ever actually specify this. A more realistic usage for this field would be: Build-Indep-Architecture: i386 for cases where the bits can only be built on a 32-bit arch; or Build-Indep-Architecture: ppc64el for e.g. cases where you are building firmware bits targeted to POWER and the most reliable way to do that is to build them same-arch instead of build-dependending on cross-compilers. Both of the above are real-world examples that I've encountered where Build-Indep-Architecture would be useful. But I know of no packages that would benefit from '!amd64' as a specification. In the first example, instead of 'i386' it would possibly be useful to be able to enumerate 32-bit architectures. This would benefit users who are building (bootstrapping) packages in an archive that doesn't have i386 as a supported architecture but does have some other 32-bit architecture available. But using '!amd64' for this is unhelpfully inaccurate, since most systems are 64-bit nowadays and one should not infer that '!amd64' means 'i386'. > We can fix my patch in a few different ways: > 1. add "an exclamation mark followed by a unique single word identifying >a Debian machine architecture ..." as one of the possible values I really don't think this is a good idea. > 2. add the ability to specify a list of architectures and/or >architecture wildcards, separated by commas Why commas? Other architecture fields in debian/control are space-delimited. > 3. both of the above, (1) and (2) > 4. drop the 'should' requirement that the field specify at least two >architectures. Yes please. > The main problem with (1), (2) and (3) is that it means a new parser has > to be written for this field, as we will be departing from the syntax of > the Architecture field. > The main problem with (4) has already been discussed: we don't want to > encourage people to just type `Build-Indep-Architecture: > my-laptops-arch` whenever their arch:all package FTBFSs on another arch. I don't see a reason to use the field definition to try to guard against that. Policy also doesn't prohibit you declaring Architecture: amd64 for packages that you have failed to port to other architectures. This is correctly enforced as distro policy, not as debian/control syntax. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#850156: Please firmly deprecate vendor-specific series files
On Wed, Apr 18, 2018 at 02:36:14PM +0200, Mike Gabriel wrote: > > This feature is a very bad idea. I can see why people thought it > > might be nice: it means you can use the same (or very similar) .dsc > > (and perhaps vcs history) on different distros. > Disagreeing here... > The vendor.series file is a really helpful thing if you share packaging > workload with people from different Debian derivatives. > My main context when working for Debian derivates is: get everything into > Debian, bind the derivatives' devs' (wo)man(or other) power to Debian and > allow them to achieve their goals for their derivative distro at the same > time. Maintaining several slightly different src:package versions in Debian > and derivative X, Y and Z costs a lot of time. > The vendor.series file is a tiny helper tool, that eases people's day if > working in a context I described above. > With Ubuntu, where the vendor.series (i.e. ubuntu.series) file is used here > and there in my team contexts, you sometimes encounter Ubuntu patches in > third party package (which you don't have impact on) that break a certain > behaviour in a vanilla Debian package. Thus, having the mechanism to easily > patch the Ubuntu build of your package is very handy. This post makes me think it all the more urgent that it be disallowed, to the point that I am considering whether Ubuntu should patch dpkg downstream to disregard vendor.series files. There are two perfectly well supported workflows here for Ubuntu: you can make your patches upstreamable (to Debian or to upstream) such that they can be applied to the source and any per-distro behavior differences can be accommodated via build-time flags; or you can keep your patches downstream in Ubuntu only, and handle new Debian package versions via a manual merge. There is no need for a third workflow to accommodate improperly-upstreamed patches and breaking the behavior of dpkg-source. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#850156: Please firmly deprecate vendor-specific series files [and 1 more messages]
On Wed, Apr 18, 2018 at 09:15:25AM -0700, Sean Whitton wrote: > Hello, > > On Wed, Apr 18 2018, Ian Jackson wrote: > > > FAOD I feel very strongly about this. The bug is over a year old. > > Can the Policy Editors please tell me when it would be apprropiate to > > escalate this to the TC ? > Sorry, I wrote my other e-mail before reading this. > ISTM that we can move towards consensus on this bug by developing > tooling that allows downstreams to make better use of dgit. That is, we > offer them something that does the work that vendor-specific series > files are doing. I don't think that should be a precondition. The examples given are for series.ubuntu, which is certainly the case I've seen in the wild. Ubuntu, as a project, did not ask for this. As an Ubuntu developer, it has never benefitted me. I have only ever seen it used by Debian developers who for some reason considered it useful to "merge" an Ubuntu delta without actually merging it. This is a development antipattern; the source package that is then automatically synced to Ubuntu from Debian is then neither under the guidance of an Ubuntu developer caring for its quality, nor benefitting from the testing of the package in Debian, because the source is no longer the same. There isn't even a guarantee that what gets synced to Ubuntu has ever been unpacked - or *can* be unpacked - with dpkg-source. So yes, please get rid of these vendor series files. It's not how any downstream is actually managing their delta from Debian. > We are actively working on the relevant processes and tools right now. > Let's see what things look like once we reach the end of that work > before escalating this bug anywhere. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#786470: debian-policy: [copyright-format] Add an optional “License-Grant” field
On Thu, Nov 30, 2017 at 09:27:30AM +, Simon McVittie wrote: > I think the License-Grant field is a useful addition to the format, > resolving some issues around whether License is meant to be the license, > the license grant or both, and I would like to be able to start using it. I strongly disagree with this. I think this adds more syntax without adding any more information. The License: field is already very consistently used to contain whatever details of the license are required to be shipped with the package - either a full text of a license, or a license grant with a pointer to /usr/share/common-licenses. If people feel that it's insufficiently obvious that this is the correct usage of the field, by all means, let's document that better; but let's not make a backwards-incompatible change to the syntax that doesn't benefit users of the file. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#850156: Please firmly deprecate vendor-specific series files
On Wed, Jan 04, 2017 at 01:41:53PM +, Ian Jackson wrote: > Package: dpkg-dev, debian-policy > Version: 1.17.27, 3.9.8.0 > dpkg-source has a surprising and not-very-well-documented feature, > that it is possible to have in a `3.0 (quilt)' package a > vendor-specific series file, which is used only if the vendor matches > that of the running host.[1] > This feature is a very bad idea. I can see why people thought it > might be nice: it means you can use the same (or very similar) .dsc > (and perhaps vcs history) on different distros. > But it is quite wrong, because it means that the same source package > has different "contents" on different computers. > In policy: > > * Say that a package MUST NOT contain a non-default series file. >(obviously with an expectation that these newly-declared RC bugs >will not be fixed in stretch) > > (And the consequential lintian change.) > > I am not yet supplying patches for dpkg-source and for policy, because > I think deprecating this feature will involve some discussion. Seconded (the sentiment, and specifically the requested policy change - though I agree it's early to do this in Policy). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Bug#835520: Policy 9.3.1 is inaccurate to the point of being harmful
On Sun, Aug 28, 2016 at 11:15:35AM +0100, Jonathan de Boyne Pollard wrote: > Sam Hartman: > >Hi. As part of reviewing an issue for the technical committee, I just read > >policy section 9.3 in its entirety. > >Section 9.3.1 really seems to be showing its age. That section covers > >runlevels and the sequencing numbers after S and K in rc.d links without > >reference to dependency-based boot ordering, init systems other than > >sysinit, etc. > >In an ideal world I'd encourage that section to be updated to talk about > >how boot ordering works on modern Debian. > >Absent that, I'd recommend significantly trimming the section to just > >cover the fact that there are run levels and that there are these numbers > >after S and K and not go into what the numbers after S and K mean. > This has just come up on the Debian Developers' mailing list, where Ansgar > Burchardt also thought of filing a bug. > The work has actually been done, if you want it. Long since. The work of revising Debian Policy includes filing a public bug report and discussing the proposed changes with the Debian Developer community via the debian-policy mailing list. Have you done this? If not, the work is not "done". But I would invite you to engage in this process and help to improve Policy. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Next update of the Policy ?
Charles, On Sat, Oct 03, 2015 at 11:23:02AM +0900, Charles Plessy wrote: > to fully implement the TC's decision, I think that it would be best to upload > the updated Policy. I see that you have committed Didier's proposed text to the git repository. This is highly inappropriate. The Technical Committee has passed a resolution that provides general technical guidance to the project. That does not mean that the TC has approved any *particular* policy language, or that the normal policy process may be bypassed in deciding the policy language. Didier's patch has seen much discussion, but exactly zero seconds from developers on the debian-policy list. Didier himself gave his approval for you committing the *cherry-picked revert* change, /not/ for committing his proposed patch. There is no evidence of consensus regarding the proposed implementation of the TC resolution, and I (among others in this discussion) do not consider this text to be in a state that's suitable for release as a new version of policy. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: debian/copyright in source package
On Wed, Aug 26, 2015 at 07:46:27AM +0900, Charles Plessy wrote: Le Tue, Aug 25, 2015 at 08:50:52PM +0200, Julien Cristau a écrit : On Sun, Aug 23, 2015 at 20:45:43 +0200, Thorsten Alteholz wrote: But policy says that there should be such a copyright file. Violating such a clause is at least an important bug. It's *at most* an important bug: I think that the disagreement here stems from that we are talking mostly about packages that are in the NEW queue and therefore are not in Debian yet. - Since they are not in Debian yet, they have no entry in the BTS, and therefore the definition of severity for issues is partly irrelevant, because: - the FTP team is free to refuse to review a package that they consider problematic enough. Here, the problem being when copyright information is too hard to find for review. These review policies are also applied when packages go through binary NEW. They are thus being applied inconsistently when new binary packages are added, and are otherwise not enforced. This is problematic on several levels. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#796642: debian-policy: hardening is an afterthought and should never be
Control: tags -1 = On Sun, Aug 23, 2015 at 12:46:22AM -0500, Richard Jasmin wrote: SELinux ENABLED and ENFORCING and INSTALLED WITH SeTroubleshoot [like Fedora has] This is not a question for policy. SELinux is not enabled by default in Debian because no one has gone to the effort of ensuring there is an SELinux policy in Debian that could work out of the box. There is nothing that policy needs to say on this question. If you are interested in seeing SELinux enabled by default in Debian, I recommend you use the Debian mailing lists (debian-devel is a good starting point) to find other people you could collaborate with to make this possible. Harden flags set AND ENFORCED on build environment(harden package) There is no way to enforce the use of hardening flags. Debian does already enable hardening flags by default, as shown by the output of 'dpkg-buildflags'. Use of RELRO and PIE where possible relro is already part of the default hardening flags. Maintainers already use PIE where it's believed possible. So what change are you looking for? NOEXEC and NOSUID on /tmp and /var/tmp dpkg needs to unpack maintainer scripts and execute them, which means unpacking to /tmp. This will never be supported so long as Debian uses dpkg. VA.randomize(HEAP?) set by default in /etc/sysctl.conf [I have many tweaks here, some for gigabit ethernet] This should be filed as a bug report against the procps package, not against policy. ENCRYPTED SWAP enabled by DEFAULT with a RANDOM key This should be discussed on debian-devel or with the debian-installer maintainers on debian-boot, not in policy. /etc/securetty set to near nothing or nothing with comments on why nothing is here and the local login methods commented. The right package for this suggestion would be the login package. However this is a nonsense suggestion, which I expect the login maintainers to rightly reject. The purpose of this file is to declare which terminals have a secure path to the host so that login knows whether or not to allow root logins. If you want to completely disallow root logins on your system, configure your system without a root password - this has nothing to do with /etc/securetty. ufw/gufw installed and set on startup fail2ban installed and base configured Default package selections: -devel or -boot, not -policy. password backups disabled Should be a bug report on the shadow package grub password protection should work (it doesnt and not only that but users and admins should have a clear cut method to enable this) Should be a bug report on the grub2 package (but possibly this is bug #545163) Documentation of mainline system installed and linked to in ~/Desktop. (Like a pdf of the debian handbook...) I don't know what documentation would be suitable here. If you have a specific recommendation (whether that's the Debian handbook or otherwise), you should probably bring this up as a bug report on the gnome package. non-free video (and other hardware) detection and installation help offered post install [like ubuntu has] It severely harms your credibility that you are complaining that Debian is not secure, and then go on to insist that Debian should make it easier to install unauditable non-free drivers. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
Re: debian/copyright in source package
On Thu, Aug 20, 2015 at 11:44:10AM +0900, Charles Plessy wrote:
On Sun, Aug 16, 2015 at 10:41:16AM -0700, Russ Allbery wrote:
I think this has come up before, and my recollection of where we ended up
in the past is that there probably isn't any *legal* reason to require
debian/copyright in source packages. However, there's a substantial
*practical* reason, namely that the existing ftpmaster tooling depends on
the existence of a source debian/copyright file for the way that they do
license reviews, and that some tooling and process changes would be
required before we can relax this requirement.
Le Sun, Aug 16, 2015 at 10:37:20PM +0200, Santiago Vila a écrit :
Yes, I think this practical reason (the ability to extract
automatically copyright files from source packages) is the main reason
why debian/copyright is required.
So we could just add it to policy as a rationale.
Dear Santiago and everybody,
how about the following ? (in section 4.5)
--- a/policy.sgml
+++ b/policy.sgml
@@ -1822,12 +1822,16 @@ zope.
sect id=dpkgcopyright
headingCopyright: filedebian/copyright/file/heading
p
Every {+source+} package must be accompanied by a verbatim copy
of its copyright information and distribution license in the
file
[-file/usr/share/doc/varpackage/var/copyright/file-]{+filedebian/copyright/filefootnote+}
{+ The filedebian/copyright/file file must be present, to+}
{+ ease the review of new packages and to facilitate automatic+}
{+ extraction of this information. It may be generated from+}
{+ templates, but not at build time./footnote+}
(see ref id=copyrightfile for further details). Also see
ref id=pkgcopyright for further considerations related to
copyrights for packages.
/p
/sect
sect
Even after that change, the sentence Every package must be accompanied by
a verbatim copy of its copyright information and distribution license in
the file /usr/share/doc/package/copyright still appears twice in the
Policy.
I disagree with clarifying Debian Policy in this direction. The practical
problem with the ftp team's tooling is a problem of their own making, and
not one that should cause more work for all Debian Developers to spend extra
time complying with a requirement which was never the intent of policy.
I will write more on this subject soon.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
Re: Can debian/rules build target use precompiled object code in favor of building from source?
On Fri, Oct 17, 2014 at 12:43:29PM -0700, Russ Allbery wrote: Thue Janus Kristensen thu...@gmail.com writes: Now in the context of the smarty3 Debian source package, I would like to know where in the policy manual it says that the debian/rules build target should actually compile from source in favor of shipping precompiled object code. However, the Debian policy manual doesn't actually seem to say that anywhere. https://www.debian.org/doc/debian-policy/ch-source.html would seem like the obvious place to say so. Am I blind, or is it perfectly OK for a Debian source package to ship and install object code, even when the source is available? This is something for which we don't have something explicit in Policy, but we do have rules in Debian. Unfortunately, not everything that you have to do to have a valid Debian package is described in Policy. In this case, the rule as it's actually enforced is not completely clear (at least to me), but roughly, it should be *possible* to rebuild the package from its original source, but it's not required to do this on every binary package build. However, a lot of folks in Debian feel like we should be moving towards doing this with every binary build, so I would expect increasing resistence against not doing so. But there are many packages in Debian right now that use the results of bison or flex instead of running bison or flex during the build, and this has traditionally been accepted. Your PHP example seems to be equivalent, so I would expect it to be accepted as well, albeit with some resistence as mentioned above, provided that generating the PHP code from the original source is still *possible*. In contrast, using binary *.o files instead of running the compiler has *not* been accepted. I think this has more to do with practical issues around the likelihood of creating bugs than any specific principle of philosophical consistency. In the specific case of smarty, the software appears to be under the LGPL. So it's a violation of the license for Debian to redistribute this without the complete source. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#754744: forbid most packages to depend on or recommend apparmor
On Sun, Jul 13, 2014 at 11:02:46PM +, Patrick Schleizer wrote:
Package: debian-policy
Severity: wishlist
Suggested policy addition:
Do not depend on or recommend the apparmor package
Packages must neither depend on nor recommend apparmor, because it would
not only enable AppArmor for this package, but for any packages shipping
an AppArmor profile, which might have unwanted effects. Enabling
AppArmor should require at least one conscious decision by the user.
If you are shipping an AppArmor profile, add apparmor to Suggests.
apparmor-{utils,profiles,profiles-extra} and other packages where this
is useful are exceptions.
Reason:
Before we can automatically enable AppArmor when the userspace tools are
installed, AppArmor maintainer intrigeri said, we must make sure, that
no packages depend on AppArmor, so AppArmor does not get installed even
though the user does not wish this. [1]
Why should apparmor be automatically enabled when the userspace tools are
installed? AFAIK this is inconsistent with how selinux is handled, which is
only enabled via an explicit boot option. Shouldn't we handle our LSMs
symmetrically?
(Also, what happens if someone has already enabled selinux, then installs
this apparmor package which is intended to automatically enable apparmor?)
Regardless, I don't think this rises to the level of something that needs
to be documented in policy, at least at this point. It seems to me that
this should be dealt with by convention among the cooperating group of
packages, with hints from lintian, and doesn't require a statement in policy
itself.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
Re: improvements to the Developers Reference maintenance workflows?
On Tue, Jul 08, 2014 at 04:14:10PM +0200, Lucas Nussbaum wrote: An easy improvement is to switch to Git and collab-maint, and to announce that direct commits of consensual changes are OK. After that, we could call for help. Raphael, Marc, are you fine with that? An update on this: I moved developers-reference to collab-maint and Git, and uploaded a new version (mainly to reflect this change in Vcs-*). I've also filed a bug (#754189) to remember to document the expected maintenance workflow. If we're going to have this in collab-maint, I think it's probably important to ensure that git commits are announced on debian-policy. Could someone set this up? Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#753608: Clarify use of conflicts, clarify what constitutes abuse of the relation
On Thu, Jul 03, 2014 at 11:52:23AM -0400, Paul Tagliamonte wrote: On Thu, Jul 03, 2014 at 05:27:21PM +0200, Bill Allombert wrote: There are precedents for such package, namely harden-servers and harden-clients What alternative to the use of Conflicts would you suggest ? I didn't know about these, interesting packages. Seems fine to me, since you'd never get this package causing dist-upgrade errors, or conflicting with essential packages. They're mostly leaf packages, as far as I can tell. Either way, I'd like to make this perfectly clear. Could you please either allow or disallow such relations in the examples? I don't believe there is a policy argument for disallowing such use of Conflicts. Good taste, yes; policy, no. It is legitimate to use Conflicts any time you need to declare that two packages should not be installed (== unpacked) at the same time, for /whatever/ reason - even if this is not related to file-level conflicts. I don't see a systemd-must-die package (conflicting with a core part of the Distro) as being productive, helpful or necessary. I definitely don't see it as there for the right reason. I don't either, but I don't think it's for policy to forbid it. If this case isn't special enough to be in policy (which may be fair, given harden-*), we can get a specific ruling on it with another team. Rather, IMHO it's too special to enshrine in policy. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#746514: Autoreconf during build
On Thu, May 01, 2014 at 01:34:05AM +0200, Bernd Zeimetz wrote: On 04/30/2014 10:36 PM, Kurt Roeckx wrote: Package: debian-policy It seems that a lot of packages do not use something like autoreconf during build, and every time someone starts a new port he has to patches way too many packages to get config.guess and config.sub updated. Do you have numbers? There is dh_autotools-dev which works well and should be a default indeed. This bug shadows a discussion on debian-devel: https://lists.debian.org/debian-devel/2014/04/msg00342.html The consensus there is that we should use dh_autoreconf over dh_autotools-dev. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Bug#727708: Both T and L are wrong, plea for something simpler
On Sat, Feb 08, 2014 at 06:15:52PM +0100, Kurt Roeckx wrote: On Sat, Feb 08, 2014 at 05:45:19PM +0100, Bill Allombert wrote: On Fri, Feb 07, 2014 at 10:13:52PM +0100, Kurt Roeckx wrote: On Fri, Feb 07, 2014 at 11:04:12AM -0800, Russ Allbery wrote: Didier 'OdyX' Raboud o...@debian.org writes: Back then, the gnome maintainers added a dependency on another package, which happened to be providing an /sbin/init. This was allowed by the Debian Policy of the time as well as by the Debian archive. The maintainers of the Policy maintainers haven't tried to rule on this at all since then. How is this matter now magically taken off the Policy maintainers' hands (while it _is_ a matter of Policy) and become a matter for the technical committee? It would be nice that other members from the policy tean could agree to that. The policy maintainers job is to maintain the policy document, not to adjudicate conflicts. I would have to disagree with that. The recent delegation among other things says defines [...] technical requirements that all packages must satisfy. What the ctte here wants to do is set policy about having a Depends on an init system. Under the delegation I think this is something for the policy editors to decide. I question the whole notion of DPL delegation of policy powers to the policy editors. The power to decide the contents of the debian-policy package follows from their status as package maintainers; package maintenance is not something that I believe it's in the purview of the DPL to delegate. What happens if the TC disagrees with the DPL's choice of policy maintainers, and exercises its power under 6.1.2 to name different package maintainers? Since this is a power expressly given to the TC, I think a consistent interpretation of the constitution requires that the DPL does not have the authority to make such a delegation. The alternative interpretation is that we have a baked-in constitutional crisis, which I don't believe is the intent. I'm not arguing that I don't think the policy editors are doing a good job - I'm grateful to them for the work they do. But constitutionally, I think the DPL doesn't have any authority to delegate the power to decide technical policy (which is a power reserved to the TC in the absence of consensus), only the power to act as recognized facilitators for policy discussions (i.e., the previous delegation that was in place). What is going on here is that as policy editors you need to set policy and that the ctte here is setting policy instead of you. The question has been asked that it is at this time allowed for them to do so. It's not up to the ctte to do detailed design work, and that they should decide between the options discussed somewhere else if they can not come to a consensus. It has been argued that this has not been discussed somewhere else, and so that it's not yet up to the ctte to decide this. What I understand that Russ is now saying is that if this was brought to the policy team, he would refer it to ctte. As delegate he can decide this on his own, but it would be nice that the other delegates didn't disagree with that. This much is reasonable, whether the policy editors' authority is delegated or not. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#707851: Soften the the wording recommending menu files: let's do it in Jessie.
On Sun, Jan 05, 2014 at 02:53:12PM +0900, Charles Plessy wrote: 9.6. Menus -- Two menu systems are used in Debian: the _FreeDesktop menu_ and the 1 _Debian menu system_. Packages shipping applications that belong to one or both menu systems should provide the necessary entry files to integrate with them. I don't think this is off to a particularly good start. The purpose of Policy is to provide maintainers with concrete guidance about how to integrate with the rest of the system. Telling maintainers there are these two systems and you can integrate with either of them as appropriate is not really providing much guidance. It doesn't tell maintainers how to determine which menu system their package belongs to, and it doesn't tell maintainers of packages that want to consume a menu which one they should use. Furthermore, I think the idea of an application belonging to one system or the other is misplaced. The purpose of both the original menu system and the freedesktop standard is to give users consistent, menu-driven access to the software installed on the computer. While a given desktop environment is going to give precedence to software that is integrated with that desktop environment, users should be able to expect that they can access all software installed on the system through the GUI, via the appropriate submenus. Telling maintainers to integrate with one of two different menu systems does not achieve this. So if the Debian menu system is insufficiently expressive to meet our needs, we should be giving clear advice for the use of the fdo menu system. * Unless hidden by default, the desktop entry must point to a PNG or SVG icon with a transparent background, providing at least the 22x22 size, and preferably up to 64x64. The icon should be neutral enough to ingrate well with the default icon themes. It integrate * In doubt, the package maintainer should coordinate with the maintainers of menu implementations through the _debian-desktop_ mailing list in order to avoid problems with categories or bad interactions with other icons. Especially for packages which are part of installation tasks, the contents of the `NotShowIn'/`OnlyShowIn' keys should be validated by the maintainers of the relevant environments. As a first cut this seems ok, but I would prefer to see more concrete guidance recorded in policy about what values of NotShowIn/OnlyShowIn should be used and when. 9.7. Multimedia handlers Media types (formerly known as MIME types, Multipurpose Internet Mail 3 Extensions, RFCs 2045-2049) is a mechanism for encoding files and data streams and providing meta-information about them, in particular their type and format (e.g. `image/png', `text/html', `audio/ogg'). # Registration of media type handlers allows programs like mail user # agents and web browsers to invoke these handlers to view, edit or # display media types they don't support directly. Packages which provide programs to view/show/play, compose, edit or print media types should register them using either the _FreeDesktop_ system or the _mailcap_ system. Again, I do not believe an either/or recommendation is appropriate here. This is abdicating the responsibility of Policy to provide concrete advice to maintainers. I believe we are at the point that we should be recommending a preference for the fdo MIME interfaces, together with appropriate transition handling to ensure proper integration with mime-support. It's possible that the transition is already handled transparently by the mime-support package and its triggers, such that no additional dependencies need to be added anywhere (since /etc/mailcap is already owned by mime-support, clearly any package which is consuming it should already be depending on it). In that case, no additional policy language is needed, other than to make it clear which of these two interfaces we are recommending that maintainers use. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#707183: debian-policy: Removal of the FHS exception for the /selinux directory
On Mon, Sep 16, 2013 at 11:45:48AM +0900, Charles Plessy wrote: Dear all, do you think it would make sense to remove the FHS exception for the /selinux directory in the next version of the Policy ? See the attached patch. Seconded. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- Charles Plessy, Tsurumi, Kanagawa, Japan Le Wed, May 08, 2013 at 09:28:57AM +0900, Charles Plessy a écrit : Package: debian-policy Severity: wishlist Dear all, in light of the message below, maybe the exception to the FHS for file/selinux/file can be removed from the Policy in the future ? Cheers -- Charles - Forwarded message from Laurent Bigonville bi...@debian.org - Date: Tue, 7 May 2013 16:51:41 +0200 From: Laurent Bigonville bi...@debian.org To: debian-de...@lists.debian.org Cc: selinux-de...@lists.alioth.debian.org Subject: Removal of the /selinux directory Message-ID: 20130507165141.1bbec...@soldur.bigon.be X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Hello, I'm planning to upload a new version of libselinux in unstable soon. This new version is dropping the /selinux directory that was used in the past as the selinuxfs mountpoint. Since Wheezy, the library is mounting selinuxfs under /sys/fs/selinux, and falling back to /selinux if the former is not available during early boot. All the selinux userspace tools and libraries should already be aware of this change. If you have packages that directly mount or manipulate the selinuxfs, you should probably check that it use the correct paths (ie. piupart, bug #682068). I'm intentionally not forcing the migration to the new mountpoint nor forcing the deletion of the directory on upgrade as, in my mind, if a Wheezy machine is still using the old mountpoint that might be for perfectly valid reasons and the package shouldn't touch it. A discussion has already been initiated on the bug report, see: #658070. Any remark on this? Cheers Laurent Bigonville - End forwarded message - From 34425d568113c741aa9f290069c6450d908f954c Mon Sep 17 00:00:00 2001 From: Charles Plessy ple...@debian.org Date: Mon, 16 Sep 2013 11:43:02 +0900 Subject: [PATCH] Policy: Remove the exception to the FHS for the /selinux directory. Wording: Charles Plessy ple...@debian.org Closes: #707183 --- policy.sgml | 17 - 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/policy.sgml b/policy.sgml index 2708242..90ae9fe 100644 --- a/policy.sgml +++ b/policy.sgml @@ -7021,15 +7021,14 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1) stable release of Debian supports file/run/file. /p /item - item -p - The following directories in the root filesystem are - additionally allowed: file/sys/file and - file/selinux/file. footnoteThese directories - are used as mount points to mount virtual filesystems - to get access to kernel information./footnote -/p - /item + item + p + The file/sys/file in the root filesystem is additionally + allowed. footnoteThis directory is used as mount point to + mount virtual filesystems to get access to kernel + information./footnote + /p + /item item p On GNU/Hurd systems, the following additional -- 1.8.4.rc3 signature.asc Description: Digital signature
Re: Built-Using, libgcc, and libc_nonshared
On Thu, May 23, 2013 at 01:34:08PM -0700, Russ Allbery wrote: In a discussion of mksh-static (see http://bugs.debian.org/709382), the question of GPL compliance for the source code of the components of libgcc and libc that are incorporated into binaries came up. mksh-static of course links statically and therefore pulls in substantial portions of library source, but there are parts of libgcc and possibly libc that are always incorporated into binaries, even ones that are dynamically linked. I had previously assumed that this did not impose any restrictions on source code availability for the libgcc and libc source because they both have run-time exceptions that basically allow one to incorporate that code into binaries under any other license without following the terms of the GPL or LGPL. However, Thorsten has raised the interesting point that the license of the source code for the binary may be GPL with no exceptions, and therefore under the GPL the resulting compiled executable is covered by the GPL and we have to provide its complete source code. That would seem to include the source for the incorporated static libgcc and libc components, since Debian cannot make use of the operating system component exception in the GPL. FWIW, my understanding is that this is one of the issues that GPLv3 attempted to bugfix with its clarification of the System Libraries exception. So to the extent that this is an issue, I believe it only applies to works that are GPLv2 only. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#698030: debian-policy: document micro binary packages (udebs).
On Sun, Jan 13, 2013 at 08:35:36AM -0800, Jonathan Nieder wrote: Bill Allombert wrote: In that case there could be a udeb subpolicy document maintained by the d-i team that policy would refer to. Yeah, that would be fine with me, even though I still don't see the point. Is there a git subpolicy describing how git is packaged? A gnome subpolicy about gnome packaging? The only difference for udebs is that the work is spread over packages throughout the system. They are still maintained by the d-i team. That's not accurate at all. The installer team are consulted on the question of which packages should be made available as udebs, but for shared libraries the maintenance of the udeb definitely lies with the library maintainer, not the installer team. So it makes perfect sense to me that we would want the requirements for udebs documented centrally where all maintainers can refer to them. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
On Thu, Dec 27, 2012 at 08:00:33AM +0900, Charles Plessy wrote: Unfortunately that would involve violating the spec. The current specification requires that every paragraph be a header paragraph, a Files paragraph, or a License paragraph. License-Exception paragraphs are not allowed. Besides, when the License field in a Files paragraph refers to a license exception, either the field must include the full text of the license or a pointer to common-licenses or the short name followed by a license exception must be defined in a License paragraph --- defining the short name and license exception in separate standalone paragraphs is not allowed. Sorry for the confusion between new field and new paragraph. Still, I think that we are spending a lot of time discussing refinements that need to demonstrate their usefulness by being adopted independantly by a broad number of package maintainers. If experimentations are blocked because the current specification does not allow unspecified types of paragraphs, how about considering to relax it ? We already had the same issue for proposed paragraphs about removed files. There's no reason experimenting should be blocked. You can put anything you want to in debian/copyright, in any format you like - you just can't call it copyright-format 1.0. Changing the header to not claim that it *is* copyright-format 1.0 is a simple requirement. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#696259: Discourage (preferably forbid) underlinked public shared libraries
On Tue, Dec 18, 2012 at 11:41:54PM +0600, Andrey Rahmatullin wrote: Package: debian-policy Severity: wishlist Hereinafter libraries means public shared libraries per Policy §8 and only them. I couldn't find in the Policy anything about underlinked libraries while I believe that having them is wrong and should be considered a bug. I mean libraries that are not directly linked against all libraries whose symbols are used. In the worst case this manifests as undefined reference lines in the ldd -r output and means that you must satisfy these references by linking additional libraries to the binaries that use the underlinked library (by linking against it or dlopening it). If you don't do this, sometimes you may not notice the problem until you invoke a specific code path that uses these references. Formally this also means that packages using the underlinked library may have RC bugs that can't be fixed, only worked around by linking additional libraries (cf. #694846 caused by #677721). Policy 10.2: Although not enforced by the build tools, shared libraries must be linked against all libraries that they use symbols from in the same way that binaries are. This ensures the correct functioning of the symbols and shlibs systems and guarantees that all libraries can be safely opened with `dlopen()'. Packagers may wish to use the gcc option `-Wl,-z,defs' when building a shared library. Since this option enforces symbol resolution at build time, a missing library reference will be caught early as a fatal build error. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: debian/copyright in case of multiple alternative licences
Hi Thomas, On Sat, Nov 03, 2012 at 03:19:59PM +0100, Thomas Friedrichsmeier wrote: Apologies, if this is not the right place to ask this kind of questions on policy. However, personally, I feel that the corresponding policy section might certainly benefit from a few words of clarification, and so I guess this list is not entirely inappropriate. Here's my question: Sections 2.3, 4.5, and 12.5 of the policy state: Every package must be accompanied by a verbatim copy of its copyright information and distribution license in the file /usr/share/doc/package/copyright. distribution license, singular. But what if there more than one licence is available? I.e.: 1) If a software to be packaged (or parts of it) is distributable under multiple alternative licences, is it allowed / recommended / required to copy all in debian/copyright? It is allowed to copy all in debian/copyright. It is required only if the distribution of this software in Debian relies on all of these licenses - e.g. if there are multiple reverse dependencies of the software, with mutually-incompatible requirements for the license of the libraries they use, such that the library must simultaneously be made available under multiple licenses. More specifically: 2) If one of the alternative licences, when standing alone, would clearly not qualify the package for inclusion in the debian archives (e.g. requires a signed agreeement), is it allowed / recommended / required to drop this particular license alternative? Allowed but never required. Also: 3) If a part of a package is distributable under multiple alternative licences, but one of these licences, when standing alone, conflicts with the licensing of the other parts of the package(*), is it allowed / recommended / required to drop this particular license alternative? Not required. However, my own recommendation is that wherever possible, binary packages should list the effective license of the binaries. Listing licenses that only apply to the sources, in the copyright file for a binary package, is unnecessarily confusing. Unfortunately we don't really have tools that support doing this right now. While at it: 4) If the copyright holder of a software packaged for debian decides to grant additional licensing alternatives, retroactively, after the package has already entered the archives. Does this mean the package should / must be updated to include this additional licence alternative(s)? You're certainly allowed to... but there's no requirement. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Debian Policy 3.9.4.0 planned for 2012-09-04
Hi Russ, On Mon, Aug 27, 2012 at 08:47:39AM -0700, Russ Allbery wrote: I plan on uploading version 3.9.4.0 of the debian-policy package on 2012-09-04. The target for this release is to incorporate accumulated fixes that catch Policy up to current behavior and current practices. Since we're in release freeze at the moment, I don't intend to pursue, for this release, changes that contradict current practice except for the implementation of the Technical Committee ruling on the build-arch and build-indep targets. If anyone has any Policy bugs that they feel meet that criteria and would like to resolve before the next upload, now is the time to try to make forward progress on them. I think the following Policy bugs meet that criteria and have proposed wording and are just waiting for additional seconds: #106073 recommend installing package docs into /usr/share/doc/package/ #542288 Versions for native packages, NMU's, and binary only uploads #640263 Clarify 9.9 - Environment variables #648271 11.8.3 says xterm passes -e option straight to exec #671355 [debconf] document escape capability I would like to suggest #591791 be added to this list. This is already implemented in the archive in startpar/sysvinit/debhelper, so this is now a matter of documenting existing practice and documenting the correct constraints on the use of upstart jobs in packages, which I think meets your criteria. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
On Mon, Aug 27, 2012 at 11:10:53AM -0700, Jonathan Nieder wrote: If I understand the policy process correctly, the N=3 requirement for patches includes the submitter; so with two other seconds, I think this is ready to go. There was an objection from Michael Biebl True. But when pressed on his aesthetic objections to this implementation, he did not offer an alternative that did not suffer from wrong interface semantics. I don't think it's reasonable to hold this up indefinitely waiting for a systemd user to design a solution he's happy with for upstart. and quite a bit of discussion after those seconds which touched on important issues There has certainly been a lot of discussion, but most of it touched on things which can/should be dealt with outside of policy. Nobody has suggested any concrete changes to the policy language in response to that discussion. The only post-seconding change was a bugfix to a code example included in the patch. , and I do not remember if the patch addressed them. Would it be a bad idea to refresh our memories by reposting the patch? The current patch is the one at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591791#294. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#684126: debian-policy: clarification needed for handling of directories used by maintainer scripts
On Thu, Aug 09, 2012 at 08:34:36AM +0900, Charles Plessy wrote: diff --git a/policy.sgml b/policy.sgml index 52dbb26..0aa08d2 100644 --- a/policy.sgml +++ b/policy.sgml @@ -3854,7 +3854,16 @@ Checksums-Sha256: pathname. Maintainer scripts should also not reset the ttPATH/tt, though they might choose to modify it by prepending or appending package-specific directories. These - considerations really apply to all shell scripts./p + considerations really apply to all shell scripts. + /p + + p + Maintainer scripts should not create directories. Instead, the + binary packages should install the directories needed for their + maintainer scripts together with the other files and directories + distributed in their data tar archive, to ensure that they are + properly removed when purging packages. + /p /sect This rationale doesn't hold up. Directories shipped in packages are removed on package removal *if* they are empty at the time (after removing all the files in the package). So any directory used by the package for data or config files that are not removed until package purge will not be removed *unless* the postrm does it. This is true whether the directory is shipped in the package or created in the postinst. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#621833: System user handling in packages: status of discussion
On Sun, Jul 01, 2012 at 12:00:25PM +0200, Marc Haber wrote: On Fri, Jun 10, 2011 at 10:12:20AM +0100, Lars Wirzenius wrote: * When the package is removed, the user should be locked: lockuser foo. * lockuser is a still-hypothetical tool, which needs to be added to the adduser package. It is a wrapper around usermod -L -e 1 foo. * Similarly, adduser needs to be changed to unlock: usermod -U -e '' foo. Why not extending deluser to not delete the user if it is a system account? Because that's contrary to the obvious meaning of 'deluser' and will be confusing to maintainers, if it doesn't actually result in the user being deleted. It's much better to have an interface that does what it says. Unclear to me are the following two points: * Should packages also remove the contents of the system account's home directory? No, the local admin might have put important additional data in there. It may be an idea to remove all files that the _package_ has put there, but that would be a _significant_ burden IMO. This should be configurable by the package maintainer using a --remove-home flag. In the general case, admins should not use per-package directories under /var/lib as a dumping ground for arbitrary files and then expect these files to be retained when the package is purged. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#621833: System user handling in packages: status of discussion
On Sun, Jul 01, 2012 at 12:01:30PM +0200, Marc Haber wrote: On Fri, Jun 10, 2011 at 11:00:14AM +0100, Roger Leigh wrote: Would lockuser need to be in the adduser package? Given that adduser is only priority:important, it's not guaranteed to be present when postrm is run, so the operation could fail. Maybe passwd is a better place for it, given that it contains useradd etc., and is priority:required. adduser should be elevated to priority:required then. adduser contains all Debian logic for account handling, while passwd doesn't. adduser is the logical place for Debianisms. No, this is not a correct use of Priority: required. The functionality *should* be in the adduser package, not in the passwd package; but that's not a sound reason to raise the priority of adduser, and raising the priority doesn't guarantee usability in the postrm anyway. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#190753: Proposing to appeal to the tech. comittee about language extensions in scripts.
On Fri, Apr 27, 2012 at 07:11:37PM +0200, Bill Allombert wrote: On Fri, Apr 27, 2012 at 06:01:52PM +0900, Charles Plessy wrote: Dear Russ, Joey, Debian Med team and evrybody, As proposed in 2010 (http://bugs.debian.org/190753#98), I would like to ask the Technical Comittee to reconsider our Policy, and restrict it to cases where the name of a program is an interface (http://bugs.debian.org/190753#128). I would like to know people's feeling about this. Hello Charles, The constitution does not grant the tech commitee the authority to override the policy process. Er, it most certainly does. 6.1. Powers The Technical Committee may: 1. Decide on any matter of technical policy. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
On Fri, Mar 16, 2012 at 11:33:26PM +0100, Michael Biebl wrote: Fwiw, this is a non-issue for systemd, as it treats sysv services and native services alike. So during the upgrade, the old sysv based service is stopped, systemd reloads the service definitions and sees that there is a native one now, and starts the new, native one. By what mechanism is the new service started? I don't see anything here distinguishing systemd from upstart. If the service is being stopped and started via invoke-rc.d, you have all the same issues. If systemd is starting the service directly, that's a gross violation of policy. Under systemd, native and sysv service are all started and tracked by systemd directly. The sysv based services are created on the fly. They simplified look like ExecStart=/etc/init.d/foo start ExecStop=/etc/init.d/foo stop etc. The invoke-rc.d foo stop call is always forwarded to systemd, which then calls /etc/init.d/foo stop, reloads the service definitions and invoke-rc.d foo start will then start the native one. So the invoke-rc.d code diverts all requests to systemd iff systemd is running? That seems like it should work ok for upgrades, yes, as in that case any service started after systemd is booted will already be a systemd unit. Where does this invoke-rc.d code live, though? I don't see it in the sysvinit-provided invoke-rc.d implementation, and I don't see a separate invoke-rc.d implementation shipped by any of the systemd binary packages. I'm wondering if this couldn't be handled in invoke-rc.d though. If upstart is running, and there is a native upstart job, which is not running though, invoke-rc.d could just call /etc/init.d/foo stop In postinst, when you run invoke-rc.d foo start, it would then start the upstart job. Wouldn't this cover this upgrade case? It would; I just don't think invoke-rc.d is the right place for that complexity to live. For instance: if upstart is running, there's an upstart job for foo, job foo is not running, and invoke-rc.d calls /etc/init.d/foo stop as a fallback: how should invoke-rc.d handle the exit code of /etc/init.d/foo? All possible answers to that question are sufficiently irksome that I think we should avoid putting the complexity in invoke-rc.d. invoke-rc.d already needs to be upstart aware, so this seems like the right place to put this logic imho. Putting it in each and every sysv init script on the other hand looks wrong to me. You didn't actually answer the question I posed here. How should invoke-rc.d handle the exit code of /etc/init.d/foo to make this not suck in the corner cases? If you don't have an answer for how to make this reliable, I don't think this aesthetic preference counts for much. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
On Fri, Mar 16, 2012 at 10:05:32PM +0100, Michael Biebl wrote: What happens in maintainers scripts that call invoke-rc.d service start? Will they now suddenly all fail? How will invoke-rc.d behave when the package both installs a upstart job and sysv init script? Doesn't this language already cover that? Instead, implementations of prgninvoke-rc.d/prgn must detect when upstart is running and when an upstart job with the same name as an init script is present, and perform the requested action using the upstart job instead of the init script. Seems I missed that, sorry. Yeah, invoke-rc.d forwarding the request to the native implementation looks fine in general. I think it would also make sense to specify, which actions are forwarded. I think policy mandates start/stop/restart/force-reload, status and reload are optional iirc. How would those be mapped to the corresponding upstart (or systemd) jobs. I think answering that is out of scope for this policy bug. It's obvious to me that the requests *must* be mapped to the native interface, and the implementation details of how that mapping is done are not interesting from a policy perspective. What are we doing about custom actions? Contrary to sysvinit, upstart and systemd don't allow custom actions. E.g. openvpn allows /etc/init.d/openvpn start vpn1 vpn2 ... vpnX Do we specify which actions invoke-rc.d forwards and if so, which ones? invoke-rc.d is an interface for maintainer scripts. I don't see any reason for a maintainer script to ever call custom actions, or for this to be specified in policy if they do. invoke-rc.d itself spits out a warning if you pass it a custom action. So I don't think this is something we should be worrying about. If invoke-rc.d intercepts and redirects the request to upstart (or systemd), should update-rc.d do the same? No. The update-rc.d policy interface is for managing a service's runlevel configuration. Those symlinks still need to be managed, regardless of whether you're running upstart, to preserve compatibility if you reboot back to sysvinit; and there is no corresponding action to be taken for upstart because upstart scripts' runlevel declarations are part of the job definition itself. Say you run update-rc.d service disable, should this disable only the sysv init script, both, or only the upstart/systemd service? 'update-rc.d disable' is not a policy interface. I think this is out of scope for this bug. But to answer the question, no, I don't think 'update-rc.d' is a sensible tool to have as an admin-oriented, init-system-agnostic interface for disabling services. 'service foo disable' would be much better. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
Oh right, should've answered this mail together with the previous, sorry. On Fri, Mar 16, 2012 at 10:46:38PM +0100, Michael Biebl wrote: If invoke-rc.d intercepts and redirects the request to upstart (or systemd), should update-rc.d do the same? Say you run update-rc.d service disable, should this disable only the sysv init script, both, or only the upstart/systemd service? The reason, why I brought this up, is this: Say you run upstart/systemd and a you have a package which provides a sysv init script foo, which you have disabled. On upgrades, invoke-rc.d will respect and not run the service. In version X, your packages starts shipping a upstart job file. In this case invoke-rc.d will happily run the upstart job. Do we require maintainers to preserve the on/off state of the service, if they start shipping a native upstart/systemd job? What would be the interface for that? Would this be a one-time migration or done on each package upgrade? Do we somehow ensure the on/off state of the service is kept consistent between the different init systems, so it doesn't matter when I switch from sysvinit to upstart (or back again)? I think preserving the on/off state of the service is a good idea, but I also think it's premature to try to specify this in policy; AFAIK there's currently no implementation for either upstart or systemd that does this. There are really two subquestions here: - When a package adds support for other init systems, how does it ensure that the override status for the service is applied to all init systems? - How should an admin disable a service to make sure it's disabled for all init systems? I think the answer to the second is definitely not 'update-rc.d disable'. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
On Fri, Mar 16, 2012 at 01:07:08PM -0700, Russ Allbery wrote: This seems like a reasonable idea. Steve, what do you think of having upstart provide such a shell library? Then init scripts could contain code along the lines of: if [ -r /lib/init/upstart.sh ] ; then . /lib/init/upstart.sh ignore_if_upstart fi If upstart and systemd can agree on the same invocation semantics for the shell library, we could even provide a shell library that handled both and make this more generic. I think this should all go in the lsb-base package (bug #661109). That's already a standard shell library for init scripts, which includes lots of functions that aren't part of the LSB standard; I don't see a good reason to contribute to a proliferation of shell libraries here. As for making it generic, while I think there should be a similar function for systemd, there needs to be some way for the init script to indicate which init systems the package actually supports natively; we wouldn't want ignore_if_not_sysvinit() for instance. It also rubs me the wrong way to have the shell library exiting directly from the init script. I'd really prefer an interface such as init_is_upstart() which leaves it open for the init script to handle some of the mentioned corner cases - in particular, allowing for action=stop to DTRT at all points during an upgrade. Also, the proposal looks underspecified to me: What happens for other actions, like stop/restart/reload/force-reload? My understanding is that calling those actions directly via the init script is not necessarily supported and invoke-rc.d should be used instead. That should probably be spelled out explicitly. Well, in the corner case of a package which calls 'invoke-rc.d restart' in postinst, and upstart is running and we're upgrading to the first version of the package which supports upstart, I see two options: - have the new version of the package call 'invoke-rc.d stop' in the preinst (before the upstart job is unpacked) so that the service is stopped via the init script. - have the new version of the package call '/etc/init.d/$service stop' explicitly in the postinst, since invoke-rc.d will now be looking at the upstart job instead. I prefer the former because it respects policy's existing guidance about not calling init scripts directly, but it also leaves a larger window when the service will be down on upgrade - and the services that have bothered to use 'restart' in the postinst usually do so to prevent exactly this. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
On Fri, Mar 16, 2012 at 09:25:17PM +0100, Michael Biebl wrote: Well, it would be inappropriate to refuse to stop the service because upstart was running. The more likely outcome is that the init script will not be able to find the running process, and will therefore exit 0 anyway as a no-op. So I don't think there are any new requirements here (which is why I didn't spell it out). If you kill the daemon from the sysv init script, upstart will just respawn it (if respawn is set) or mark it as failed. Sorry, I was unclear. What I meant was that, in the upgrade case where upstart is already running but the service is not yet under control of upstart, /etc/init.d/$service stop still needs to make sure it stops the daemon if running. The implementation should be careful to *not* kill processes that were spawned via upstart; but in general that can be handled by ensuring the upstart job doesn't create a pidfile that would confuse the init script, and in the worst case it'd just be: stop) if init_is_upstart status $service | grep -q start then exit 0 fi [...] Now alternatively, we could make it always an error to call /etc/init.d/$service stop when there's an existing upstart job, and have this command return non-zero just as for the start case. But that requires us to *guarantee* that the pre-upstart service is stopped *before* unpacking the upstart-aware init script on the system, and that falls afoul of the restart-in-postinst case. Personally, I would just prefer, if the shell library would forward the action requests to the native init system. But this falls down horribly during the upgrade in a very error-prone manner. Another problematic issue that comes to mind, is packages installing dhcp and ifup.d hooks which call /etc/init.d/service start From my recollection, there are at least a few that do this, the most prominent one is nfs-common. I don't see any such hook script in nfs-common. I see a few hooks that call *reload*, which is always safe to call regardless of any invoke-rc.d or runlevel policy. But calling '/etc/init.d/$service start' directly from a hook would be just as broken as calling it from a maintainer script, because it bypasses said policy. So this should be a non-issue. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
On Fri, Mar 16, 2012 at 04:19:15PM -0500, Jonathan Nieder wrote: Example for context: http://bugs.debian.org/445203#50 Which points to: http://bugs.debian.org/588085 Given that there's a separate policy bug for this, I'm not sure what bearing this has on the upstart discussion. Could we perhaps take this to the other bug? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
On Fri, Mar 16, 2012 at 03:14:18PM -0500, Jonathan Nieder wrote: By the way, the above example writes the path to initctl to the terminal when it is present, which I imagine is not intended. Indeed not. Updated example in the attached patch. [...] Also, the proposal looks underspecified to me: What happens for other actions, like stop/restart/reload/force-reload? Yes, I agree. The example should be corrected to prevent the daemon from being started by the restart and force-reload actions. This is difficult to include as part of a useful example if we expect the init script to still handle the stop case, because the restart and force-reload actions are so often implemented on top of start+stop. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org From ab57ead712ceaf0c02f68c27f308fb08344fd4a2 Mon Sep 17 00:00:00 2001 From: Steve Langasek steve.langa...@canonical.com Date: Sun, 9 Jan 2011 19:58:58 -0600 Subject: [PATCH] Document generic and upstart-specific init-system requirements Add a new section on alternative init systems that outlines the compatibility requirements for both init replacements and packages shipping upstart jobs. Closes: #591791 --- policy.sgml | 68 +++ 1 files changed, 68 insertions(+), 0 deletions(-) diff --git a/policy.sgml b/policy.sgml index b3c5886..610777d 100644 --- a/policy.sgml +++ b/policy.sgml @@ -7188,6 +7188,74 @@ Reloading vardescription/var configuration...done. /p /sect + sect id=alternateinit +headingAlternate init systems/heading +p + A number of other init systems are available now in Debian that + can be used in place of packagesysvinit/package. Alternative + init implementations must support running SysV init scripts as + described at ref id=sysvinit for compatibility. +/p +p + Packages may integrate with these replacement init systems by + providing implementation-specific configuration information about + how and when to start a service or in what order to run certain + tasks at boot time. However, any package integrating with other + init systems must also be backwards-compatible with + packagesysvinit/package by providing a SysV-style init script + with the same name as and equivalent functionality to any + init-specific job, as this is the only start-up configuration + method guaranteed to be supported by all init implementations. An + exception to this rule is scripts or jobs provided by the init + implementation itself; such jobs may be required for an + implementation-specific equivalent of the file/etc/rcS.d//file + scripts and may not have a one-to-one correspondence with the init + scripts. +/p +sect1 id=upstart + headingEvent-based boot with upstart/heading + + p +Packages may integrate with the prgnupstart/prgn event-based +boot system by installing job files in the +file/etc/init/file directory. SysV init scripts for which +an equivalent upstart job is available must query the output of +the command prgninitctl version/prgn for the string +ttupstart/tt and avoid running in favor of the native +upstart job, using a test such as this: + example compact=compact +if [ $1 = start ] which initctl /dev/null initctl version | grep -q upstart +then + exit 1 +fi + /example + /p + p +Because packages shipping upstart jobs may be installed on +systems that are not using upstart, maintainer scripts must +still use the common prgnupdate-rc.d/prgn and +prgninvoke-rc.d/prgn interfaces for configuring runlevels +and for starting and stopping services. These maintainer +scripts must not call the upstart prgnstart/prgn, +prgnrestart/prgn, prgnreload/prgn, or prgnstop/prgn +interfaces directly. Instead, implementations of +prgninvoke-rc.d/prgn must detect when upstart is running and +when an upstart job with the same name as an init script is +present, and perform the requested action using the upstart job +instead of the init script. + /p + p +Dependency-based boot managers for SysV init scripts, such as +prgnstartpar/prgn, may avoid running a given init script +entirely when an equivalent upstart job is present, to avoid +unnecessary forking of no-op init scripts. In this case
Bug#591791: systemd point of view
On Mon, Dec 26, 2011 at 11:04:27AM -0800, Russ Allbery wrote: The patch seems mostly ok to me. I think we should decide whether we want a single invoke-rc.d that everybody uses and which knows how to handle all of sysvinit, upstart and systemd or if we want each init system to ship their own. From the patch, it looks like each init system should ship their own, but that it still must keep compatibility with all other implementations. I agree that this should be spelled out, since the behavior of invoke-rc.d is rather important in this proposal. Currently, it says: Instead, implementations of prgninvoke-rc.d/prgn must detect when upstart is running and when an upstart job with the same name as an init script is present, and perform the requested action using the upstart job instead of the init script. in the upstart section, which implies *all* implementations of invoke-rc.d, including the one that comes with sysvinit. Was the intention that this would only apply to the one that comes with upstart itself? So currently, invoke-rc.d is part of the sysv-rc package, and there's an alternative implementation in the file-rc package. I had envisioned that these packages would continue to own the invoke-rc.d and update-rc.d interfaces, as they do on Ubuntu, and be the focal point for bridging the differences between the different init systems. I didn't mean that the init systems themselves should implement invoke-rc.d, but that the one coming with whichever implementation of rc is used on the system should support all the init systems. Shipping an invoke-rc.d implementation in upstart and/or systemd would mean either a lot of code duplication, or a pass-through with dpkg-divert. I'm not enthusiastic about either idea, but if push came to shove (i.e., if the sysvinit maintainers rejected patches to support upstart in invoke-rc.d), I would opt for the latter. Also: Dependency-based boot managers for SysV init scripts, such as packageinsserv/package, may avoid running a given init script entirely when an equivalent upstart job is present, to avoid unnecessary forking of no-op init scripts. In this case, the boot manager should integrate with upstart to detect when the upstart job in question is started or stopped to know when the dependency has been satisfied. This is optional, but I'd still like to get review of this part from the insserv maintainers. (Did that happen somewhere earlier in this thread already?) Bug #660824, with initial positive feedback from one of the sysvinit comaintainers. (This should be corrected to say startpar rather than insserv since insserv only generates the dependency information, it's startpar that acts on it at boot time. Fixed in my patch.) Don't we need to say something about how alternative boot managers should arrange to take over init, given that sysvinit is Essential, so that we don't break things while doing so? I guess that's bug #645540, and subsequent discussion on debian-devel in http://lists.debian.org/debian-devel/2012/02/msg00309.html ff. Policy doesn't really speak to this at present anyway, so I would be content to let the maintainers of the small set of packages involved figure this out among themselves. Finally, given the recommendation: SysV init scripts for which an equivalent upstart job is available must query the output of the command prgninitctl version/prgn for the string ttupstart/tt and avoid running in favor of the native upstart job. I'd really like to see Policy provide some sample code for how to do that, since otherwise people are going to get this wrong. Ok, example included based on the patch in bug #661109. Updated patch attached. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org From 4542bf3f70be85e0e6eecd754c8530ebf2c71a77 Mon Sep 17 00:00:00 2001 From: Steve Langasek steve.langa...@canonical.com Date: Sun, 9 Jan 2011 19:58:58 -0600 Subject: [PATCH] Document generic and upstart-specific init-system requirements Add a new section on alternative init systems that outlines the compatibility requirements for both init replacements and packages shipping upstart jobs. Closes: #591791 --- policy.sgml | 68 +++ 1 files changed, 68 insertions(+), 0 deletions(-) diff --git a/policy.sgml b/policy.sgml index b3c5886..b390db2 100644 --- a/policy.sgml +++ b/policy.sgml @@ -7188,6 +7188,74 @@ Reloading vardescription/var configuration...done. /p /sect + sect id=alternateinit +headingAlternate init systems/heading +p + A number of other init systems are available now in Debian
Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
On Sun, Feb 26, 2012 at 05:12:24PM -0600, Jonathan Nieder wrote: --- a/policy.sgml +++ b/policy.sgml @@ -7188,6 +7188,74 @@ Reloading vardescription/var configuration...done. [...] + p +Because packages shipping upstart jobs may be installed on +systems that are not using upstart, maintainer scripts must +still use the common prgnupdate-rc.d/prgn and +prgninvoke-rc.d/prgn interfaces for configuring runlevels +and for starting and stopping services. These maintainer +scripts must not call the prgnstart/prgn, +prgnrestart/prgn, prgnreload/prgn, or prgnstop/prgn +commands directly. When I first read this, I wondered if in a postinst containing # Automatically added by dh_installinit if [ -x /etc/init.d/vsftpd ]; then update-rc.d vsftpd start 20 2 3 4 5 . stop 80 1 . /dev/null invoke-rc.d vsftpd start || exit $? fi # End automatically added section the invoke-rc.d vsftpd start line should be removed when I add an upstart job. Possible cause: the word directly is being asked to do too much. Would the following be too strict? Maintainer scripts should not execute /etc/init.d/package scripts directly. I think you've misunderstood the intent here. When upstart is installed, it provides *commands* called start, restart, reload, and stop in /sbin. These are the commands that must not be called from maintainer scripts. It has nothing to do with invocation of /etc/init.d/package scripts, which is already prohibited elsewhere in policy. Is there a word that you think would be less ambiguous than command for expressing this? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
On Sun, Feb 26, 2012 at 04:00:11PM -0800, Russ Allbery wrote: Steve Langasek vor...@debian.org writes: I think you've misunderstood the intent here. When upstart is installed, it provides *commands* called start, restart, reload, and stop in /sbin. These are the commands that must not be called from maintainer scripts. It has nothing to do with invocation of /etc/init.d/package scripts, which is already prohibited elsewhere in policy. Is there a word that you think would be less ambiguous than command for expressing this? Oh, yes, I misunderstood that too. How about: These maintainer scripts must not call the upstart prgnstart/prgn, prgnrestart/prgn, prgnreload/prgn, or prgnstop/prgn interfaces directly. which uses the same term (interfaces) that is used for calling invoke-rc.d and update-rc.d? Looks good to me. Attached. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org From 1747168e17852e062039f5b5680a127522ca3fb7 Mon Sep 17 00:00:00 2001 From: Steve Langasek steve.langa...@canonical.com Date: Sun, 9 Jan 2011 19:58:58 -0600 Subject: [PATCH] Document generic and upstart-specific init-system requirements Add a new section on alternative init systems that outlines the compatibility requirements for both init replacements and packages shipping upstart jobs. Closes: #591791 --- policy.sgml | 68 +++ 1 files changed, 68 insertions(+), 0 deletions(-) diff --git a/policy.sgml b/policy.sgml index b3c5886..57e9a3b 100644 --- a/policy.sgml +++ b/policy.sgml @@ -7188,6 +7188,74 @@ Reloading vardescription/var configuration...done. /p /sect + sect id=alternateinit +headingAlternate init systems/heading +p + A number of other init systems are available now in Debian that + can be used in place of packagesysvinit/package. Alternative + init implementations must support running SysV init scripts as + described at ref id=sysvinit for compatibility. +/p +p + Packages may integrate with these replacement init systems by + providing implementation-specific configuration information about + how and when to start a service or in what order to run certain + tasks at boot time. However, any package integrating with other + init systems must also be backwards-compatible with + packagesysvinit/package by providing a SysV-style init script + with the same name as and equivalent functionality to any + init-specific job, as this is the only start-up configuration + method guaranteed to be supported by all init implementations. An + exception to this rule is scripts or jobs provided by the init + implementation itself; such jobs may be required for an + implementation-specific equivalent of the file/etc/rcS.d//file + scripts and may not have a one-to-one correspondence with the init + scripts. +/p +sect1 id=upstart + headingEvent-based boot with upstart/heading + + p +Packages may integrate with the prgnupstart/prgn event-based +boot system by installing job files in the +file/etc/init/file directory. SysV init scripts for which +an equivalent upstart job is available must query the output of +the command prgninitctl version/prgn for the string +ttupstart/tt and avoid running in favor of the native +upstart job, using a test such as this: + example compact=compact +if [ $1 = start ] which initctl initctl version | grep -q upstart +then + exit 1 +fi + /example + /p + p +Because packages shipping upstart jobs may be installed on +systems that are not using upstart, maintainer scripts must +still use the common prgnupdate-rc.d/prgn and +prgninvoke-rc.d/prgn interfaces for configuring runlevels +and for starting and stopping services. These maintainer +scripts must not call the upstart prgnstart/prgn, +prgnrestart/prgn, prgnreload/prgn, or prgnstop/prgn +interfaces directly. Instead, implementations of +prgninvoke-rc.d/prgn must detect when upstart is running and +when an upstart job with the same name as an init script is +present, and perform the requested action using the upstart job +instead of the init script. + /p + p +Dependency-based boot managers for SysV init scripts, such as +prgnstartpar/prgn, may avoid running a given init
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
On Sun, Dec 18, 2011 at 03:22:04PM -0600, Jonathan Nieder wrote: Ximin Luo wrote: OK, understood. I will take a look at creating a patch for copyright-format.xml like you did. However, I think I would prefer using an explicit grammar instead (e.g. the sort that programming language specifications use), because that leads to clearer thinking and less ambiguity. Which would you prefer? That's up to Steve, since he's the editor of the document. I am personally of two minds --- on one hand, I would like to see the copyright-format released quickly, which means making only minimal changes to the document. On the other hand, an explicit grammar would indeed make the details of the spec easier to understand. I guess if I were in your shoes, I'd keep a grammar in mind and make sure the text specifies it unambiguously but use plain text so as to make the changes not too invasive. It would be nice to have a formal grammar down the line, but that's also too large of a change for 1.0. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#654958: debian-policy: Document VCS fields.
On Sat, Jan 07, 2012 at 08:46:47AM -0800, Russ Allbery wrote: I wonder if something like Vcs-Git: git://git.eyrie.org/kerberos/webauth.git squeeze could be made to work. My understanding was that the debcheckout developers were not enthused about adding a syntax that Git upstream didn't support, but I think that's the only solution that anyone's come up with so far. On the other hand, it is kind of silly for them to be in such widespread use without Policy saying anything about them. Maybe we should just document them as they are and be explicit about the limitations, saying things like: The information in the Vcs-* header should be sufficient to locate the repository used for packaging and access it anonymously. It may or may not be the branch used for packaging any specific version of the package, and the packaging is not necessarily on the default branch. Additional investigation is often required to find the part of the repository used for current development or for any particular version of the package. If, over time, debcheckout and our package metadata starts making more explicit guarantees, we can always tighten the language later, but the above reflects the current state of the archive. I object to policy specifying any Vcs-* fields in a way that does not uniquely identify a Debian packaging branch. Running debcheckout for a package only to then have to guess at random which of 20 branches is the one containing the packaging I care about[1] is nonsense, and I don't think this has any business being in policy in the absence of sensible semantics. The field should in all cases point to the right branch, not just the right repository, and in the absence of an acceptable per-branch URI syntax, it ought not be standardized at all. Now, given that git seems to be the only widespread VCS with theis problem, I wouldn't object to codifying Vcs- fields for the others in the meantime; but some people might find it equally unpalatable to specify fields for everything except git. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org [1] E.g., Vcs-Git: git://git.debian.org/~lamont/util-linux.git signature.asc Description: Digital signature
Bug#654958: debian-policy: Document VCS fields.
On Sun, Jan 08, 2012 at 09:55:48PM +0900, Charles Plessy wrote: From what I see in Sid, only 37 Subversion URLs contain the string ‘branch’. This matches well with the practice I know in the Debian Med and Debian Science teams, where we indicate the trunk. Yes. By the nature of svn, the Vcs-Svn URI always unambiguously refers to a single branch (trunk is a branch). It's *only* the Vcs-Git usage is broken. Vcs-Svn and Vcs-Git are by far the most frequent fields. In my opinion, the thousands of packages using them define a common practice, and for that reason I think that it should be documented in the Policy. Policy is for documenting what *SHOULD* be done. It doesn't matter if it's 10 or 1000 packages that are using Vcs-Git today; if the syntax is broken, it shouldn't go in policy. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#620870: debian-policy: Please add /run as FHS exception
On Sun, Jan 01, 2012 at 09:58:45AM -0800, Russ Allbery wrote: Comments, objections, seconds? Seconded. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org diff --git a/policy.sgml b/policy.sgml index 79281e9..0bdc891 100644 --- a/policy.sgml +++ b/policy.sgml @@ -6246,6 +6246,25 @@ install -m644 debian/shlibs.varpackage/var debian/varpackage/var/DEBIAN/ symlinked there, is relaxed to a recommendation. /p /item + item + p + The additional directory file/run/file in the root + file system is allowed. file/run/file + replaces file/var/run/file, and the + subdirectory file/run/lock/file + replaces file/var/lock/file, with + the file/var/file directories replaced by symlinks + for backwards compatibility. file/run/file + and file/run/lock/file must follow all of the + requirements in the FHS for file/var/run/file + and file/var/lock/file, respectively, such as file + naming conventions, file format requirements, or the + requirement that files be cleared during the boot + process. Files and directories residing + in file/run/file should be stored on a temporary + file system. + /p + /item item p The following directories in the root filesystem are @@ -6388,6 +6407,35 @@ rmdir /usr/local/share/emacs 2/dev/null || true though the spool may still be physically located there. /p /sect1 + + sect1 id=fhs-run + headingfile/run/file and file/run/lock/file/heading + + p + The directory file/run/file is cleared at boot, normally + by being a mount point for a temporary file system. Packages + therefore must not assume that any files or directories + under file/run/file other than file/run/lock/file + exist unless the package has arranged to create those files or + directories since the last reboot. Normally, this is done by + the package via an init script. See ref id=writing-init + for more information. + /p + + p + Packages must not include files or directories + under file/run/file, or under the + older file/var/run/file and file/var/lockfile paths. + The latter paths will normally be symlinks or other + redirections to file/run/file for backwards compatibility. + /p + + p + Packages should use file/run/file in preference + to file/var/run/file and file/run/lock/file in + preference to file/var/lock/file. + /p + /sect1 /sect sect @@ -6762,15 +6810,14 @@ test -f varprogram-executed-later-in-script/var || exit 0 /p p - file/var/run/file and file/var/lock/file may be mounted - as temporary filesystemsfootnote - For example, using the ttRAMRUN/tt and ttRAMLOCK/tt - options in file/etc/default/rcS/file. - /footnote, so the fileinit.d/file scripts must handle this - correctly. This will typically amount to creating any required - subdirectories dynamically when the fileinit.d/file script - is run, rather than including them in the package and relying on - prgndpkg/prgn to create them. +Files and directories under file/run/file, including ones +referred to via the compatibility paths file/var/run/file +and file/var/lock/file, are normally stored on a temporary +filesystem and are normally not persistent across a reboot. +The fileinit.d/file scripts must handle this correctly. +This will typically mean creating any required subdirectories +dynamically when the fileinit.d/file script is run. +See ref id=fhs-run for more information. /p /sect1 -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878vlrb8yy@windlord.stanford.edu -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120102000239.gb21...@virgil.dodds.net
Bug#649679: [copyright-format] Clarify what distinguishes files and stand-alone license paragraphs.
On Mon, Dec 19, 2011 at 10:34:24AM +0100, Jakub Wilk wrote: * Charles Plessy ple...@debian.org, 2011-12-19, 10:12: Of course, I agree that making a stand-alone License paragraph with an extra Fiels field would be an horror. But I am inclined to think that it is obvious enough that we do not need to constrain the syntax. With the change you propose extra checks are needed while parsing. I thought it was obvious when I implemented lintian checks, but it turns out to not be so easy after all. The problem is with paragraphs like this: | Copyright: 2042, J. Random Hacker | License: BSD-6-clauses | Redistribution and use in source and binary forms, with or without | modification, are permitted provided that the following conditions | are met: blah, blah, blah, blah, blah and blah. In early DEP-5 drafts, Files field could be ommited in certain circumstances, so this could have been a perfectly valid files paragraph. But with the current DEP-5 version, if we allow any extra fields, this suddenly becomes a valid stand-alone license paragraph. Please see bug #652380 for a real-world example. Meh. When someone writes their debian/copyright with this line at the top: Format: http://dep.debian.net/deps/dep5 then they have no business complaining when parsers and validators reject the file as not being compliant with the current version of the spec. More to the point, lintian should *not* be trying to accept such files on the basis that this was once considered valid. Lintian should be enforcing the current spec on anything that claims to be a DEP5 file, not trying to support all kinds of intermediate forms as valid. Now if there were a Format: line at the top pointing at a url that lintian doesn't know about, it would be reasonable to skip the rest and simply note that an unrecognized format is being used. But when the file says it's using DEP-5, it should be DEP-5. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#649679: [copyright-format] Clarify what distinguishes files and stand-alone license paragraphs.
On Mon, Dec 19, 2011 at 10:12:52AM +0100, Charles Plessy wrote: I don't think that should be legal either however; we allow extra fields to be added to any paragraph, but I don't believe the intent is to allow *defined* fields to be used in paragraphs where they are not specified to be permitted - only to allow new field names to be used. So I think something like the attached patch should be applied. Thoughts? I am sometimes using an extra Source field in some Files paragraphs, when they define works that are not the creation of the main authors, especially when it was difficult to find their original upstream location. Why use the same field name (Source) in the Files paragraphs as in the header paragraph when this is not defined - instead of using, say, 'Component-Source' (or even just 'Comment')? Have you proposed making this use of Source part of the standard? If so I'm afraid I missed that. I can understand that you would want to document the source of individual components in cases where the whole work is no longer available, but I think that reusing an already-defined field name for the purpose just makes it harder for validators to distinguish between accidental errors and deliberate extensions. Indeed, there is already one recommendation in the spec for exactly this purpose: No prefixing is necessary or desired, but please avoid names similar to standard ones so that mistakes are easier to catch. There's nothing more similar to a standard field name than one which is identical. ;) Of course, I agree that making a stand-alone License paragraph with an extra Fiels field would be an horror. But I am inclined to think that it is obvious enough that we do not need to constrain the syntax. With the change you propose extra checks are needed while parsing. If nevertheless the consensus is to apply your changes, I would like to suggest to normalise the vocabulary: either “extra fields” or “additional fields”, but the current patch uses both. The Policy's chapter 5 uses “additional”, so this is where my choice would go even if it will increase the difficulty to search for previous discussions on the topic. That's fair. Updated patch attached. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org === modified file 'dep5/copyright-format.xml' --- old/dep5/copyright-format.xml 2011-12-18 17:38:43 + +++ new/dep5/copyright-format.xml 2011-12-19 18:23:14 + @@ -108,14 +108,17 @@ mandated upstream information, copyright notices and licensing details. /para para - The syntax of the file is the same as for other Debian control files, as - specified in the Debian Policy Manual. See its ulink + The syntax of the file is the same as for other Debian control files, + as specified in the Debian Policy Manual. See its ulink url=http://www.debian.org/doc/debian-policy/ch-controlfields#s-controlsyntax;section - 5.1/ulink for details. Extra fields can be added to any paragraph. No - prefixing is necessary or desired, but please avoid names similar to - standard ones so that mistakes are easier to catch. Future versions of - the filenamedebian/copyright/filename specification will attempt to - avoid conflicting specifications for widely used extra fields. + 5.1/ulink for details. Additional fields can be added to any + paragraph, but the fields defined in this document are only allowed in + the paragraphs where they are specified to be present. No prefixing + is necessary or desired for new field names, but please avoid names + similar to standard ones so that mistakes are easier to catch. Future + versions of the filenamedebian/copyright/filename specification + will attempt to avoid conflicting specifications for widely-used + additional fields. /para para The file consists of two or more paragraphs. At minimum, the file signature.asc Description: Digital signature
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
On Sun, Dec 18, 2011 at 12:24:03AM -0600, Jonathan Nieder wrote: I disagree strongly. The cost of giving maintainers *different* ways to represent the license status is much higher than the cost of requiring maintainers to separately reproduce license headers for components that are GPL-2 licensed vs. GPL-2+. Reading this in the context of the text you are replying to, I fear I don't understand. I didn't mention multiple licenses or multiple ways to represent license status at all, so this reply feels like a non-sequitor. While it's useful to see that you disagree strongly, I'm not sure what you disagree strongly with. In your message, you said that you didn't think it should be required to split the license notice into a comment field but that it should be allowed, and you offered a patch addressing this. Allowed means the author of the file has a choice about which way to do it, and that's not appropriate. However, I don't think there is anything to act on immediately in this report, except clarifying one detail: Since standalone license paragraphs are used to expand license short names and GPL-2+ with OpenSSL exception is not a short name but a short name with an exception, do I understand correctly that license exceptions cannot be put in stand-alone License paragraphs? I don't believe that's the intent at all. I think this is perfectly valid: Files: * Copyright: The Man in the Moon, 2007 License: GPL-2+ with OpenSSL exception License: GPL-2+ with OpenSSL exception This program is free software [...] as a special exception, [...] On Debian systems, [...] Perhaps the spec should be clarified to make this more explicit? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#649679: [copyright-format] Clarify what distinguishes files and stand-alone license paragraphs.
On Wed, Nov 23, 2011 at 12:19:18PM +0900, Charles Plessy wrote: I forward here Dominique's comment from ‘http://bugs.debian.org/642833#66’. (see also the next messages in that thread). Le Tue, Sep 27, 2011 at 04:21:07PM +0200, Dominique Dumont a écrit : Consider the following (admitedly contrived) copyright paragraph: Files: this license applies to any of them License: GPL-1+ GPL-1+ yada yada Is it: - a Files paragraph with a License field ? - a License paragraph with an extra Files field ? Perhaps we can clarify how to distinguish files and stand-alone license paragraphs. The attached patch is in line with what lintian and config-model do. I think this particular patch has been superseded by the refactoring of paragraphs definitions vs. field definitions done in the DEP repo. Since we now explicitly state that a Files paragraph has the Files, Copyright, and License fields as required, the paragraph shown above is not a Files: paragraph (it's missing a Copyright field). So perhaps it's a stand-alone License paragraph with an extra Files: field. I don't think that should be legal either however; we allow extra fields to be added to any paragraph, but I don't believe the intent is to allow *defined* fields to be used in paragraphs where they are not specified to be permitted - only to allow new field names to be used. So I think something like the attached patch should be applied. Thoughts? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org === modified file 'dep5/copyright-format.xml' --- old/dep5/copyright-format.xml 2011-12-18 17:38:43 + +++ new/dep5/copyright-format.xml 2011-12-18 22:49:01 + @@ -108,14 +108,17 @@ mandated upstream information, copyright notices and licensing details. /para para - The syntax of the file is the same as for other Debian control files, as - specified in the Debian Policy Manual. See its ulink + The syntax of the file is the same as for other Debian control files, + as specified in the Debian Policy Manual. See its ulink url=http://www.debian.org/doc/debian-policy/ch-controlfields#s-controlsyntax;section - 5.1/ulink for details. Extra fields can be added to any paragraph. No - prefixing is necessary or desired, but please avoid names similar to - standard ones so that mistakes are easier to catch. Future versions of - the filenamedebian/copyright/filename specification will attempt to - avoid conflicting specifications for widely used extra fields. + 5.1/ulink for details. Additional fields can be added to any + paragraph, but the fields defined in this document are only allowed in + the paragraphs where they are specified to be present. No prefixing + is necessary or desired for new field names, but please avoid names + similar to standard ones so that mistakes are easier to catch. Future + versions of the filenamedebian/copyright/filename specification + will attempt to avoid conflicting specifications for widely used extra + fields. /para para The file consists of two or more paragraphs. At minimum, the file signature.asc Description: Digital signature
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
that, at the base of the DEP, there are the requirements of the Debian policy, of the Debian archive administrators, and the common practice. In the case of the (L)GPL, it is common practice to use the license notices as found in headers of files as if they were the actual license text. First because the Policy §12.5 specifies that the copyright file should point at /usr/share/common-licenses instead of quoting these licenses, and second because the Archive administrators require us to include these headers (http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html) I am arguing that the common practise is incorrect. The first reason does not hold: pointing to a license file is different to including a license notice because a license notice is NOT a *license*, it often contains extra information (like authors and which software). The second reason also does not hold: That email you quoted is about the copyright file as a whole, whereas I am only arguing against the License: stanza. Of course the file as a whole must contain information equivalent to a license notice. But the License: stanza must not, as I argued before. You are asking to redefine the meaning of the field which has been consistently accepted when discussing this proposed standard for more than a year. That's not going to happen. To be consistent, you must pick one of these two: - License: paragraphs can't be split - they specify the entire terms for a given set of files. MPL or LGPL or GPL is separate license from LGPL or GPL and they each need separate License: paragraphs - License: paragraphs can be split into common components, and relicensing comments be pushed back into the File: paragraph, and disallowed to be in the License: paragraph. This forbids many many license notices which often contain such information. The first option is not acceptable because it requires reproduction of long licenses such as the MPL multiple times in a single file. The second option is not acceptable first, because it's a substantial change to the semantics of the DEP5 format, and that's not happening for 1.0; second, because of the issue mentioned above about embedding logic in parsers that shouldn't be there; and third, because the license terms of the work in question *are* that you may distribute it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version, and it is wholly false to say that this information does not belong in a license field. You may find the current behavior inconsistent, but it's the right thing to do. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#466550: Fixed in 2.8.0
reopen 466550 thanks On Fri, Dec 16, 2011 at 09:52:01PM +0100, Jelmer Vernooij wrote: Version: 2.8.0 This bug was fixed in upstream version 2.8.0.o bzr-builddeb now warns when using the get-orig-source target in debian/rules to fetch the currently package upstream tarball. get-packaged-orig-source should be provided instead. This is a bug filed against debian-policy, though, not against bzr-builddeb. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#620870: debian-policy: Please add /run as FHS exception
On Mon, Nov 28, 2011 at 09:08:18PM +0100, Bill Allombert wrote: Would anybody object to Roger patch being applied without the reference to /run/shm, and leave this particular topic to another bug report ? Beside, I attach an alternative patch by Thomas Hood that I found in the log but which was not send to the list. One concern I have about this patch is that it replaces references to /var/run and /var/lock with /run and /run/lock, but the only explanation that /run should be used in place of /var/run is in a non-normative footnote. So we've effectively lifted the prohibition on shipping files under /var/run with this change, which isn't really what we want. Should it be spelled out in the normative bits of policy that packages should use /run for anything that the FHS says should be in /var/run, and that packages must not ship files under any of /run, /var/run, or /var/lock? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org --- policy.sgml_ORIG 2010-07-26 06:44:57.0 +0200 +++ policy.sgml 2011-06-21 13:10:15.815787305 +0200 @@ -5987,11 +5987,30 @@ item p The following directories in the root filesystem are - additionally allowed: file/sys/file and - file/selinux/file. footnoteThese directories - are used as mount points to mount virtual filesystems - to get access to kernel information./footnote -/p + additionally allowed: file/run/file, + footnote +The purpose of the /run hierarchy is storage of ephemeral +system state, that is, state information that should +not be preserved across a reboot. +Files and directories residing in file/run/file +should be stored on a temporary filesystem. +The file/run/file directory is a +replacement for file/var/run/file; its +subdirectory file/run/lock/file is a replacement for +file/var/lock/file. +/run/ and /run/lock/ have been introduced +by most distributions and are on track to be +endorsed by the FHS. +Additionally, the subdirectory file/run/shm/file +is a replacement for file/dev/shm/file. + /footnote + file/sys/file and file/selinux/file. + footnote +The file/sys/file and file/selinux/file +directories are mount points where +virtual filesystems are mounted which provide access +to kernel information. + /footnote /item /enumlist @@ -6489,15 +6508,17 @@ /p p - file/var/run/file and file/var/lock/file may be mounted - as temporary filesystemsfootnote - For example, using the ttRAMRUN/tt and ttRAMLOCK/tt - options in file/etc/default/rcS/file. - /footnote, so the fileinit.d/file scripts must handle this - correctly. This will typically amount to creating any required - subdirectories dynamically when the fileinit.d/file script - is run, rather than including them in the package and relying on - prgndpkg/prgn to create them. +Files and directories under file/run/file, including those +in directories file/var/run/file and file/var/lock/file +which are symlinks or bind mounts to subdirectories of +file/run/file, are normally stored on a temporary +filesystem and are normally not persistent across a reboot. +Consequently, packages cannot assume that these files or +directories are present at system boot time. +Files and directories under file/run/file must not be +included in packages; such files or directories +must be created dynamically, for example, in the +fileinit.d/file script. /p /sect1 signature.asc Description: Digital signature
Bug#630174: debian-policy: forbid installation into /lib64
On Sun, Nov 27, 2011 at 11:55:20AM +0900, Charles Plessy wrote: Le Sat, Jun 25, 2011 at 04:28:41PM -0500, Steve Langasek a écrit : On Sat, Jun 11, 2011 at 10:58:02PM +0200, Julien Cristau wrote: On Sat, Jun 11, 2011 at 13:49:53 -0700, Russ Allbery wrote: Here is a patch. According to apt-file, prohibiting to install files into /lib64 and /usr/lib64 on amd64 would make only one package RC-buggy, juffed, in its experimental version. I'm not sure why your apt-file invocation wouldn't have turned it up, but libc6 in unstable installs /lib64/ld-linux-x86-64.so.2. So as written this would make libc RC buggy, which is not what we want. (At the time of the previous discussion, libc was not installing this to /lib64; the change was made as a result of a more thorough analysis of the consequences of multiarch on i386 systems.) Also, this shouldn't spell out with architecture amd64. Packages on *all* architectures must avoid use of /lib64 and /usr/lib64, with a handful of exceptions. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org From 8a708ce2125835e537566fc1f75094d91076f573 Mon Sep 17 00:00:00 2001 From: Charles Plessy ple...@debian.org Date: Sun, 27 Nov 2011 11:40:21 +0900 Subject: [PATCH] Forbid installation into /lib64 and /usr/lib64. Closes: #630174 --- policy.sgml |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/policy.sgml b/policy.sgml index 3122632..47fbfb4 100644 --- a/policy.sgml +++ b/policy.sgml @@ -6185,8 +6185,8 @@ install -m644 debian/shlibs.varpackage/var debian/varpackage/var/DEBIAN/ /item item p - The requirement for amd64 to use file/lib64/file - for 64 bit binaries is removed. + Packages with architecture amd64 must not install files + in file/lib64/file and file/usr/lib64/file. /p /item item -- 1.7.5.4 signature.asc Description: Digital signature
Bug#633797: copyright-format: with keywords exception underspecified
I've committed the below patch to the dep repo on svn.debian.org. === modified file 'web/deps/dep5.mdwn' --- old/web/deps/dep5.mdwn 2011-11-11 15:27:02 + +++ new/web/deps/dep5.mdwn 2011-11-25 20:15:33 + @@ -1036,12 +1036,27 @@ target=_topmany versions of the MIT license/a. Please use Expat instead, when it matches./p -pExceptions and clarifications are signaled in plain -text, by appending tt class=literalwith code class= -varnamett class= -replaceableikeywords/i/tt/code exception/tt to +pAn exception or clarification to a license is signaled +in plain text, by appending tt class=literalwith code +class=varnamett class= +replaceableikeyword/i/tt/code exception/tt to the short name. This document provides a list of keywords -that refer to the most frequent exceptions./p +that must be used when referring to the most frequent +exceptions. When exceptions other than these are in effect +that modify a common license by granting additional +permissions, you may use an arbitrary keyword not taken +from the below list of keywords. When a license differs +from a common license because of added restrictions rather +than because of added permissions, a distinct short name +should be used instead of tt class=literalwith code +class=varnamett class= +replaceableikeyword/i/tt/code exception/tt. +/p + +pOnly one exception may be specified for each license +within a given license specification. If more than one +exception applies to a single license, an arbitrary short +name must be used instead./p pThe GPL tt class=literalFont/tt exception refers to the text added to the license notice of each file as -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: New policy is not consensual
Hi David, On Sun, Nov 20, 2011 at 10:04:29PM -0400, David Prévot wrote: On 02/11/2011 11:17, Alexander Reichle-Schmehl wrote: As you might have noticed, I send some mails. Let's first see, if we can reach a consensus, let's say... by the end of the week. Alexander, you wrote this message two weeks ago, is there any chance you could try and help us find a way out of the current issue? Even if we're not able to address the general case, as a general rule or something like that, maybe addressing the specific case that raised the initial thread could permit us to go back working on the DPN. TL;DR: Jeremiah's remarks on the list makes me think I might have been misunderstood. While discussing off list this issue with other persons, it seems like this request is not completely silly, so let me try to express the reason why I believe that Debian should not promote this initiative. Debian currently does not claim that people should give it money in order to get free stuff. Debian currently doesn't act a la Wikipedia with “give us money” campaigns. If the Debian project wants to take position in favor of such campaign (for itself), I do believe this decision should not be taken lightly, and may deserve a rationale debate about it. If Debian promotes (by mentioning the existence of) a third party initiative claiming that “give us money” campaigns are fine in order to get free stuff, in the name of good for Debian, Debian would de facto claim that such initiative is fine, bypassing the rationale debate it may need. Until an official Debian position emerge in favor of this kind of fund-raising campaigns, I propose that the DPN editors won't relay them without at least an internal consensus. Did you mean to post this to debian-policy? Debian-policy is the mailing list for discussions of Debian's *technical* policy; you seem to be discussing some other sort of political policy, but I'm not sure what you're referring to because there's no context for your post to this list. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#633797: copyright-format: with keywords exception underspecified
On Wed, Nov 16, 2011 at 09:31:05AM +0900, Charles Plessy wrote: Le Tue, Nov 15, 2011 at 09:16:18AM +0900, Charles Plessy a écrit : Le Wed, Jul 13, 2011 at 10:21:58PM +0200, Jakub Wilk a écrit : copyright-format reads: | Exceptions and clarifications are signaled in plain text, by appending | with keywords exception to the short name. However, it is not specified how different keywords are separated. For example, should one write: License: GPL-2+ with OpenSSL and Font exception or License: GPL-2+ with OpenSSL, Font exception or maybe License: GPL-2+ with OpenSSL Font exception? I looked at how my favorite parser, config-edit, is doing with exceptions, and if I add a ‘OpenSSL and Font’ or an ‘OpenSSL, Font’ exception, it stops with error at loading… I inspected the 11,575 packages available on the Lintian Lab. 489 License statements had the word “exception” in. None of them were double exceptions. Is there a concrete example where we need to support multiple exceptions ? If not, I propose to follow and document the current practice, which is to support only one. This has the advantage that it will not be needed to implement new functions in parsers, nor to correct copyright files. I have no objection to this for 1.0, provided we at the same time clarify that if more than one exception is in use, you need to use a custom shortname instead of an ORed or ANDed list of licenses. Is there a consensus for this position? I think for future versions of the standard, it's worth covering this case even if it's only a hypothetical; but there's no reason to hold up 1.0 for something that's going to require parser changes and isn't in use anywhere. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#648387: [copyright-format] English proofreading.
On Sun, Nov 13, 2011 at 11:01:05AM -0600, Jonathan Nieder wrote: To consolidate related changes, let's wait however a little for additional propositions. For instance, I would like to suggest to replace “dash” by “hyphen” I disagree here. Please file separate reports for separate proposals, unless the text they affect and subject matter seem to overlap a lot and the proposed text is already ready. DEP drivers: do these changes look reasonable to you? Policy delegates: does this require formal seconds, or is it just an informative change? I think the effort to have this proofread by debian-l10n-english at this stage is misguided, because there are serious problems with the *standards language* of the current draft, which makes it nearly impossible for implementors to get things right due to the resulting ambiguities. I haven't reviewed the proposed diff, but I don't expect a proofreading effort to have resulted in significant improvements. Charles inquired privately whether I objected to this strategy, but only waited a day before requesting proofreading from debian-l10n-english, so, shrug I think merging such changes (which at a glance appear to include arbitrary preferences of word choice) is a waste of everyone's time and I'm inclined to ignore this altogether in favor of working on the real problems with the text. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#633797: copyright-format: with keywords exception underspecified
On Tue, Nov 15, 2011 at 09:16:18AM +0900, Charles Plessy wrote: Le Wed, Jul 13, 2011 at 10:21:58PM +0200, Jakub Wilk a écrit : copyright-format reads: | Exceptions and clarifications are signaled in plain text, by appending | with keywords exception to the short name. However, it is not specified how different keywords are separated. For example, should one write: License: GPL-2+ with OpenSSL and Font exception or License: GPL-2+ with OpenSSL, Font exception or maybe License: GPL-2+ with OpenSSL Font exception? I think that this is a good point, but I am unsure if we have the capacity to fix it before releasing version 1.0 of the format. I definitely would not object. There's no point in declaring the spec 1.0 while ambiguities like this one remain. This is in fact on the list of issues that I consider blockers for DEP5. On Mon, Nov 14, 2011 at 06:24:18PM -0600, Jonathan Nieder wrote: As a workaround, with keyword exception might work, making this GPL-2+ with OpenSSL exception with Font exception. :) Does GPL-2+ with OpenSSL and Font exceptions work (note the plural)? I would be happiest if GPL-2+ with anything worked, as free-form text. You can always say GPL-2+-with-anything as a custom license name, but the value in spelling out standardized license tags at all as part of the spec is that it allows for mechanical extraction (and eventually, automated checking of license compatibility and accuracy of license information). If it's going to be extended in a free-form manner, what's the value in partially specifying the name? One benefit, certainly, is that you can assume that GPL with foo exception(s) gives you at *least* all the same rights that the GPL does, since GPL exceptions can only grant additional permissions and not take them away. However, the history of the draft shows that people are concerned about knowing whether *specific* common exceptions are in effect, so I think the spec should include a standardized way of expressing these common exceptions, including in combination. Of the various options suggested above for combining exceptions, I have no strong preferences; I think it would be bikeshedding to spend overly long discussing the options. Does anyone else have a preferred option that we could quickly reach consensus on and enact? I have a slight preference for: GPL-2+ with OpenSSL and Font exceptions because it's both easy to parse and reads naturally in English. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#648387: [copyright-format] English proofreading.
On Mon, Nov 14, 2011 at 07:24:21PM -0600, Jonathan Nieder wrote: Steve Langasek wrote: I think merging such changes (which at a glance appear to include arbitrary preferences of word choice) is a waste of everyone's time and I'm inclined to ignore this altogether in favor of working on the real problems with the text. So, to be clear, does that mean that (assuming they don't change the meaning) you object to these changes, or only that you do not want to spend time dealing with them? In other words, if some portion of the everyone whose time is wasted wants to spend time that way, would that be a problem? Yes, it's still a problem because it steals time from the policy editors and/or DEP drivers away from substantive issues. And when I say I'm inclined to ignore it, I mean that I don't think I'm going to merge this into the dep repo. For what it's worth, I find the text more readable after JBR's changes than before. I don't think readability matters much when it still doesn't say what it needs to. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#591791: systemd point of view
Hi Tollef, Picking up this policy thread after a bit... Let's see if we can drive this to a conclusion now. On Fri, Feb 04, 2011 at 10:11:40PM +0100, Tollef Fog Heen wrote: From the proposed policy patch: + SysV init scripts for which +an equivalent upstart job is available must query the output of +the command prgntelinit --version/prgn for the string +ttupstart/tt and avoid running in favor of the native +upstart job. My system actually already has upstart installed, but doesn't use it, so upstart's telinit will have to be fixed to not report «upstart» in its version string if the running init is not upstart. That's slightly orthogonal to this bug report, but it shows that you can't necessarily depend on the output of --version and such to know what's running. This will also affect people on migration from one init system to another. Right. I've looked around, and the better interface to use here is 'initctl version'; this command tries to query the running init daemon over the upstart-specific control socket and fails if it can't connect. Of course, if the initctl command doesn't exist at all on the system, this will fail. +Dependency-based boot managers for SysV init scripts, such as +packageinsserv/package, may bypass a given init script +entirely when an equivalent upstart job is present, to avoid +unnecessary forking of no-op init scripts. What happens to the dependency resolution of insserv in that case? I'd much rather have insserv not do anything and the non-sysvinit init system be smart and parse LSB headers rather than insserv seeing that A depends B, but B is missing (since it's provided by a systemd service/upstart job) and then flake out. This was a good question, which took me a while to answer. The answer I've come up with is http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2011-October/005345.html. It's a deliberate design decision for upstart to not support parsing of LSB headers of init scripts, instead delegating this to insserv (and delegating the execution to /etc/init.d/rc). The linked patch, however, allows startpar to recognize when a dependency should be satisfied by an upstart job instead of by the corresponding init script. I'd also like us to forbid depending on implementation-specific scripts such as mountkernfs since there won't necessarily be anything that maps to in a non-sysvinit world. The exception would be if an init script is shipped as part of the init system, so sysv-rc's scripts could have dependencies on mountkernfs, but random daemons could not. udev already depends on mountkernfs as part of the rcS sequence. Of course, the entire rcS sequence should be replaced by the alternative init system, but this will still require cooperation between several packages. I'm not sure whether this needs to be documented in Policy per se, or with what level of granularity. I do think there's a bootstrapping tangle here, in that I don't want to start pushing patches to sysvinit, lsb-base, and debhelper until we have the basic Policy agreed upon, and I don't think we'll be able to discern a correct policy for things like mountkernfs until we've gotten fairly far along with implementing it. So if you don't mind, I'd like to split this particular issue off to be dealt with separately. A final thing I'd like to get added to the policy text is how standardised facility names are handled. insserv for some reason does not handle init scripts providing $x-display-manager and similar, but requires those to be added to the insserv configuration file. We should either require init implementations to allow providing the standardised facility names or we should put that information somewhere in a a neutral location and format so all init implementations can make use of it. Does this refer to aliases standardized in the LSB, or to some other standard? (I'd answer this for myself, but once again it looks like I can't find the text of the LSB when I'm looking for it...) Updated patch attached. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org From 06b2b04a925acd4acab2697c8b62ace9a24364a6 Mon Sep 17 00:00:00 2001 From: Steve Langasek steve.langa...@canonical.com Date: Sun, 9 Jan 2011 19:58:58 -0600 Subject: [PATCH] Document generic and upstart-specific init-system requirements Add a new section on alternative init systems that outlines the compatibility requirements for both init replacements and packages shipping upstart jobs. Closes: #591791 --- policy.sgml | 62 +++ 1 files changed, 62 insertions(+), 0
Bug#591791: extend init.d policy to permit upstart jobs and describe their use
Hi Jonathan, On Sat, Mar 05, 2011 at 02:19:12AM -0600, Jonathan Nieder wrote: + tasks at boot time. However, any package integrating with other + init systems must also be backwards-compatible with + packagesysvinit/package by providing a SysV-style init script + with the same name as and equivalent functionality to any + init-specific job, as this is the only start-up configuration + method guaranteed to be supported by all init implementations. An + exception to this rule is scripts or jobs provided by the init + implementation itself; such jobs may be required for an + implementation-specific equivalent of the file/etc/rcS.d//file + scripts and may not have a one-to-one correspondence with the init + scripts. Maybe policy could allow (but discourage) packages that only support some non-Sys-V init system as long as they include a dependency indicating so? I don't think that's something that should be allowed. You can only have one init system installed at a time; and all of the interesting alternatives to sysvinit are currently Linux-only. So if maintainers start choosing to only support one of the alternatives, they will quickly fragment the distribution (because not all maintainers are going to choose the *same* alternative), and they will render their packages unusable on our non-Linux ports. The only reason for any package to provide only an upstart job, or only a systemd config, is if it's a cooperating package providing part of the base boot sequence for that init system. (E.g., mountall for upstart.) One of the advantages of upstart and its kin is the simpler configuration, after all, so I can imagine some maintainers wanting to take advantage of that and not having time to debug a standard init script. The example that led me to mention this is Bug#422139; it is not quite the same issue but is related. Having written many upstart jobs, I understand the appeal of not having to maintain a sysvinit script for backwards-compatibility. However, the slow movement of upstart in Debian so far, and this policy bug proposing rules for alternate init systems, are specifically about ensuring that we do *not* lose backwards-compatibility. Now, if someone were to write a tool to automatically translate an upstart job into an init script, that might be an interesting way to handle this; but most upstart jobs will be missing information about things like how to ask a daemon to create a pid file, or where the pid file will be stored, so the applications might still be limited. As a naïve user, I'd prefer the SysV init scripts to pass on requests to upstart when upstart is running; is that feasible? It would be feasible to pass requests to upstart, but it would be unnecessary. If the upstart job is properly declared, upstart will have already started it in the runlevel (or queued it for starting) before the init script ever has a chance to ask; and for admin invocations, a frontend like the 'service' command is more user-friendly anyway. I suspect it would be best to make the language init system neutral, and to say something to this effect: . sysvinit scripts need to behave reasonably regardless of the init system in use. So: i. If an equivalent job file for another init system is present, the sysvinit script will not be automatically invoked by that init system when switching runlevels. In this case, when that init system is in use, the sysvinit script (if invoked by hand, for example) must either delegate requests to the init system or error out without doing anything. Don't fight with init(8). ii. Even if an equivalent job file for another init system is available, the sysvinit script should behave as advertised (and not be a no-op) when init is sysvinit. I agree that these are the relevant principles, but I think Policy should spell out exact requirements for each init system. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#643690: perl policy unclear about the section for manpages
Package: debian-policy Version: 3.9.2.0 The perl policy makes confusing statements about the section that manpages should be installed in: 2.4. Documentation -- Manual pages distributed with Perl packages must be installed into the standard directories: [...] Modules Manual pages for modules are installed into `/usr/share/man/man3' with the extension `.3perl'. 4.1. Vendor Directories --- The installation directory for Debian modules must be different from that for core and site modules. [...] Module packages must install manual pages into the standard directories (see Section 2.4, `Documentation') using the extensions `.1p' and `.3pm' to ensure that no conflict arises where a packaged module duplicates a core module. I apparently misread this long ago and assumed that manual pages for modules was talking about all modules rather than just those from the perl source package. Only a recent lintian warning, showing me that MakeMaker has output the manpage with a .TH that doesn't match the filename, clued me in. I think the language in 2.4 should be clarified to explicitly state this only applies to modules from the perl source package. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110928174017.gc7...@virgil.dodds.net
Re: alternative dependency ordering - with respect of packages in main
On Thu, Sep 22, 2011 at 10:25:06PM +0200, Bill Allombert wrote: I know that the buildd system likes to pull in the first package in such an alternative dependency chain. And now I start to wonder: Is it allowed for a package in main to have a package _outside_ of main as first component of an alternative dependency? The package in question is extremely unlikely to ever be used as Build-Depends, so this is of a more general question. What also might be used as argument is the social contract, DFSG #4: Our priorities are our users and free software -- it can be argued that we don't put the priority on free software in such a case. tl;dr - what do you think, is a Depends: foo-contrib | foo acceptable for packages in main or should it be Depends: foo | foo-contrib instead? Policy 2.2.1 forbid both usages: it says: the package must not declare a Depends, Recommends, or Build-Depends relationship on a non-_main_ package Nowhere in policy there is an indication that the first alternative is special. That is a bug in the policy wording. What is meant by Depends relationship and Recommends relationship is the package must not under a normal configuration cause a package outside of main to be pulled in to satisfy the dependency, which is the *relationship* expressed; it does not mean that a non-free package may not appear anywhere in the Depends *field*. I suggest that foo-contrib Provides: foo instead. Are you sure that can't give results that are contrary to policy's intent? Whereas 'Depends: foo | foo-contrib' will always install the real 'foo' by preference, as far as I know once you make foo-contrib Provides: foo, 'Depends: foo' could result in 'foo-contrib' being given preference arbitrarily. Or does apt have a guarantee that real packages will be given preference, or that main packages will be given preference over non-free ones, when resolving virtual packages? In any case, you can't have versioned provides, so there are some use cases where this would still not be sufficient. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#638060: debian-policy: §9.1.1: FHS should also be a must for generated files
On Tue, Aug 16, 2011 at 11:33:06PM +0200, Axel Beckert wrote: Policy 9.1.1 states: The location of all installed files and directories must comply with the Filesystem Hierarchy Standard (FHS) [...]. IMHO this should not only cover installed files (which I interpret as files being shipped in packages) I think this is a wrong interpretation. There's nothing in policy that defines installed files the way you've interpreted it here, and I've seen no evidence of confusion on this point on the part of package maintainers up to now - we clearly have a distribution which complies with the FHS for both files shipped in packages and files generated by packages. I also think that all of the suggested wording changes in this bug are worse than what we currently have, because they make the language much less clear. So I would rather see this bug closed as wontfix than see any of the proposed patches applied. On the other hand, local debian packages for propritary software generated by scripts shipped in a Debian package do not need to comply to the FHS. Why do you think they don't need to comply with the FHS? Note of course that comply with the FHS does not mean install to /usr. It is not clear where to draw the line between these extremes, for example, would a script that installs a software to a non-standard location (e.g., because upstream has weird opinions about such things) after asking the user to confirm this be allowed in Debian? It would probably be allowed. However, it would still be buggy under Policy. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#609160: debian-policy: include DEP5
On Sun, Aug 28, 2011 at 02:30:34PM +0100, Lars Wirzenius wrote: On Sun, Aug 28, 2011 at 04:41:28PM +0900, Charles Plessy wrote: given that DEP 5 is still in the CANDIDATE state, and given that the change is not normative, I was wondering if the patch I sent in November 2011, reproduced below for your convenience, could be applied in the end. My opinion on this hasn't changed. I'm still hoping that the DEP5 spec will properly integrated into the policy package soon, and I would prefer to see that happening, so that my involvement in it can end, than make any other changes right now. My opinion also has not changed: I think there are significant language bugs in the current draft that should be fixed before this is ready to be adopted as a standard. Whether these are dealt with via the DEP process or on debian-policy makes no difference to me, but I for one am not happy to see this integrated into policy as-is. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#487201:
On Sun, Aug 28, 2011 at 12:24:55AM +0100, Ximin Luo wrote: You missed my point. Verbatim text in copyright may be mechanically extractable, but not easily verifiable. It's hard in the general case to verify that a license block called MPL actually contains the full correct MPL text, both for machines and humans. First, this is only hard for humans, not hard for machines; it's *trivial* to convert a block of license text into a case-insensitive, whitespace-smashing normalized form for comparison. And any DEP5 parser is going to strip out the ' .' lines as well. Second, an important feature of the DEP5 format is the use of standard keywords for common licenses. If you have a DEP5 debian/copyright where you declare it's under the MPL, and the text of the license is not the MPL, *that's a bug*, and one that can be reliably and automatically detected by software. No software does this today, because no one has taken the time to write it yet, but it's a problem that can be solved by writing the code once. In the meantime, *users* can reasonably assume that if the package declares the code to be under 'License: MPL-1.1', this is the license that applies, without any need for long, by-hand comparison of license texts. To re-quote myself - one might see that a package points to MPL.txt [or a license paragraph with the MPL header], then assume it's the MPL, but then strongwhy have that file [or text] there in the first place, if you're not going to read all of it/strong? Because not everyone who cares to know what rights they have to the software knows what the MPL is (or has its terms memorized) in the first place! -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#487201:
On Sun, Aug 28, 2011 at 02:00:33AM +0100, Ximin Luo wrote: Thanks for the explanation; I didn't find this in the places I looked. Still, the fact that the right way takes much more effort than the multitude of wrong ways is not a good thing. This is often true of both life and software. The solution is to make it easier to get it right, not to change our mind about what the right thing is. If you were to write a program that could report the copyright status of every single file on the system, it would be weird if you showed a slightly different GPL3 for different files. Even if you parsed a license text to a canonical form, I doubt this would be a visually pleasing form, or even one that has a coherent logical structure. e.g. Steve suggested collapsing whitespace - but this loses (e.g.) paragraph information. How you decide to format the license text for display is an *entirely* separate question from checking whether the license text is correct. I never suggested using the case- and whitespace-smashed form for display (or even storing it as a file). Realistically, I don't think anyone is going to choose the MPL simply because they see it in /usr/share/common-licenses. Also, it seems the anti-MPL stance is just from a few people, rather than the Debian project as a whole, e.g. [1] says it's fine. It would be equally wrong to omit the MPL for the same reason. [1] http://wiki.debian.org/DFSGLicenses#Mozilla_Public_License_.28MPL.29 This documents that Debian has decided that the MPL meets the DFSG and that it's acceptable for inclusion in main. That does *not* mean that it is a license that Debian (or Debian developers individually) recommends the use of or would like to see adopted more widely. In fact, one of the two mails cited by that wiki page as supporting evidence[1] includes this comment from Anthony Towns: That a license is DFSG-free doesn't mean it's good any more than a license not being DFSG-free means it's bad -- there are lots of reasons to not use DFSG-free licenses or software under the licenses, and there are lots of reasons to use and work on software that's under DFSG-non-free licenses. The DFSG is *Debian's* free software guidelines, that're meant to be useful for *Debian* to make decisions. Personally, if I've got a choice, I don't use licenses that are GPL incompatible, eg, which the MPL certainly is. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org [1] http://lists.debian.org/debian-legal/2007/07/msg00215.html signature.asc Description: Digital signature
Bug#625449: Permanent BSP patch
Hello, This bug came up for discussion this evening at DebConf; I think it's overdue to be followed through on. Lucas seems to agree in the end with my own believe that there is a weak consensus in favor of the proposed policy, and it does effectively reflect current practice, so I think applying this patch in some form is the right thing. The biggest remaining point of contention seems to be whether an RC bug which has had a response from a maintainer indicating that it's in progress should be covered by the 0 day policy after 7 days, or if it should be covered by the 2 day policy. Since this is contentious, I propose the more conservative policy be applied, as per the attached patch. Comments? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org Index: pkgs.dbk === --- pkgs.dbk (revision 8898) +++ pkgs.dbk (working copy) @@ -1947,6 +1947,11 @@ itemizedlist listitem para +Upload fixing only release-critical bugs older than 7 days, with no maintainer activity on the bug for 7 days and no indication that a fix is in progress: 0 days +/para +/listitem +listitem +para Upload fixing only release-critical bugs older than 7 days: 2 days /para /listitem signature.asc Description: Digital signature
Bug#633994: debian-policy: confusion over what the license information in the copyright file actually means
On Fri, Jul 15, 2011 at 07:50:31PM +0100, Nicholas Bamber wrote: In particular in DEP-5 format the contention is that the sort license stanza specifies the upstream license and the long form Debian license. In any case there is an inconsistency between the stated version 1.1+ and the license text which mentions 1.2. Actually, I don't think there is a mismatch here. This is something that, I think, is the case with many other Debian packages, including some maintained by the Debian Perl Group :) The author states 1.1 or later and the packager *chooses* to point the reader to a later version - the one in the common-licenses package, 1.2. You may see an example of this in e.g. the libmailtools-perl or libtemplate-perl packages, among others. So the question is should the requirements (either in policy or DEP-5) be tightened up or left intentionally vague? So to be clear, the claim here is that it's ok to list License: LGPL-2+ (or something of the sort), but have the license stanza contain the text of LGPL-3? Or if that's not what you mean, could you please provide a concrete example of the usage at issue? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#633994: debian-policy: confusion over what the license information in the copyright file actually means
On Fri, Jul 15, 2011 at 02:14:09PM -0500, Jonathan Nieder wrote: Nicholas Bamber wrote: As far as I know the license data in debian/copyright states what license Debian is distributing the package under. Section 1.2 Copyright information says: Every package must be accompanied by a verbatim copy of its copyright information and distribution license While there's been some debate before about what verbatim means, I suspect that most would agree that, for example, changing 1.1 or later to 1.2 would not be it. I would not agree with this. First and foremost, the purpose of the debian/copyright file is to notify *users of the Debian package* what their rights are. It is entirely appropriate for this file to therefore encode information about the *effective* license, rather than about the *original* license. If the Debian maintainer has opted to distribute under a later version clause and not pass through the permission to distribute under an old (possibly buggy) license, or if the library linking we're doing when combining this work with another in the distro means that the binaries are only distributable under a later version, this is perfectly appropriate to indicate in debian/copyright. Maintainers have done this for years already (although not universally, because it's a lot more work than just copying whatever text is in the upstream sources and letting users work out the effective rights for themselves). If someone cares about distinguishing between the upstream granted license and the effective license, that's going to require much better tooling for automating this than we have now. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#633994: debian-policy: confusion over what the license information in the copyright file actually means
On Fri, Jul 15, 2011 at 08:30:53PM +0100, Nicholas Bamber wrote: The package maintainer wants the following stanza Copyright: (C) 1995-1998, 2000, 2003-2008 Free Software Foundation, Inc. License: GFDL-1.1+ Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with the Front-Cover texts being ``A GNU Manual,'' and with the Back-Cover Texts as in (a) below. . On Debian systems, the full text of the GNU Free Documentation License version 1.2 can be found in `/usr/share/common-licenses/GFDL-1.2'. Thanks for providing the specifics. IMHO this is perfectly fine as-is. We are correctly pointing to a license text in /usr/share/common-licenses which matches the terms under which the work is being distributed (Debian uses GFDL 1.2 only, not 1.1), and we are complying with the original license terms. I don't see any reason to include a copy of, or even provide a pointer to, an older buggy license which we're not using. I also wouldn't have a problem with it if the maintainer were to replace '1.1' with '1.2' in the license declaration, fwiw. I don't know whether a clarification in policy is needed to cover this. (I don't think it's a syntactic question, so doesn't really belong in DEP-5.) Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#630174: debian-policy: forbid installation into /lib64
On Sat, Jun 11, 2011 at 10:58:02PM +0200, Julien Cristau wrote: On Sat, Jun 11, 2011 at 13:49:53 -0700, Russ Allbery wrote: Currently, section 9.1.1 relaxes the FHS requirement that /lib64 and /usr/lib64 be used, but it doesn't prohibit installing files in that location. However, due to the way Debian handles this (with symlinks), bad things happen in terms of tracking files and conflicts if packages install files into /lib64 and /usr/lib64 and rely on these symlinks. I think we should instead prohibit (must not) installing files into /lib64 and /usr/lib64 in packages with architecture amd64. Sounds sensible to me. I agree. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#604397: debian-policy: require build-arch and build-indep targets
On Tue, Jun 07, 2011 at 09:39:59AM +0200, Bill Allombert wrote: One thought I had today was what will happen with packages using either cdbs or dh. Both of these provide build-arch and build-indep rules, and as a result both can build using those targets today (though individual packages may of course be broken if they did things in the wrong rules). However, each would require updating individually to actually enable their use. Autodetection here would prevent the need for this. It would not. Currently autobuilder always only install Build-Depends, so 'debian/rules build' has to work with only Build-Depends installed. This means there has basically two cases for package having build-arch/build-indep: a) Packages do not have Build-Depends-Indep. b) Packages have Build-Depends-Indep but the documentation is built in binary-indep instead of build-indep. To get any advantage from this proposal, packages a) need to be changed to have a proper Build-Depends-Indep line. Packages b) already provides the split anyway. There are two benefits of this intended change: avoiding the downloading and installation of heavy build-dependencies only needed for generation of architecture-independent packages; and avoiding the build-time generation of those architecture-independent packages. Existing packages that have properly structured their debian/rules targets already for the second case would get immediate benefit from autodetection, with no further changes. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#604397: Request for TC to rule on a course of action for supporting build-arch
unmerge 604397
clone 604397 -1
reassign -1 tech-ctte
retitle -1 Please rule on how to implement debian/rules build-arch
merge 345619 604397
thanks
Fellow Committee members,
I am requesting your assistance in helping the project come to a conclusion
about how we can support the use of the 'build-arch' debian/rules target on
autobuilders, letting us at long last split Build-Depends and
Build-Depends-Indep the way they're meant to be split.
As you can see from the history of the source bug, this question has
lingered for some time - the first policy bug having been opened over 5
years ago. I believe it has remained unresolved principally because we have
several different ways that the problem could be solved, each of which is
better than not solving it but none of which is overwhelmingly superior to
the others. As a result, it has taken longer to decide how to implement
this than it would have taken us to actually implement it, even using one of
the methods that require touching every affected package in the archive.
I think that makes this one of the rare cases where the TC can usefully move
Debian forward by voting rather than by seeking consensus, because the root
problem here is the *lack of a decision* rather than any real technical
dispute about the right course of action.
The Technical Committee has sufficient authority to address this question
under any of §6.1.{1,2,4,5}. If you prefer, we could also ask for a
referral from the policy editors or the dpkg maintainers, to eliminate any
question of supermajority requirements.
If this were to be put to a vote today, I would propose the following ballot
options:
1) Implement support for calling 'debian/rules build-arch' in place of
'debian/rules build' by checking for the presence of the target using
'make -qn'.[1]
2) Implement support for calling 'debian/rules build-arch' with a fallback
to 'debian/rules build' by checking whether the output of the build-arch
target matches that of a dummy target.[2]
3) Implement support for calling 'debian/rules build-arch' in place of
'debian/rules build' if a Build-Options field is set in debian/control
of the source package specifying that this target is supported.[3]
4) Turn on direct use of 'debian/rules build-arch' on the autobuilders for
all packages in unstable and experimental immediately, with no fallback
if the target does not exist; requires a corresponding update to Policy
and mass updates to fix packages that fail to build as a result.
5) Further Discussion
None of these options require extensive design work on the part of the TC;
where patches don't already exist, the implementation should be trivial.
I'm happy to expand on each of these options and present the pros and cons
as I see them, or you can each peruse the extensive historical record at
your leisure... :)
My own vote would likely be: 1, 2, 3, 5, 4. (I could be persuaded to rank 4
above FD if this were the only way to move forward; but that's indisputably
the most disruptive to the archive, so I would hope we could reach agreement
that some or all of the other options are better.)
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
[1] http://lists.debian.org/debian-devel/2007/07/msg00048.html
[2] http://bugs.debian.org/598534
[3] http://bugs.debian.org/229357
signature.asc
Description: Digital signature
Bug#604397: debian-policy: require build-arch and build-indep targets
On Mon, Jun 06, 2011 at 02:33:22PM +0100, Roger Leigh wrote: While neither of these changes actively enforces the addition of these targets, neither do any harm, and by actively encouraging adoption of the targets it will reduce the total number of NMUs required should we go for the approach of a straight change in dpkg-buildpackage. Neither of these dictate /how/ the transition should proceed, which is a separate issue which you brought to the CTTE, but both will be needed irrespective of the choice picked by the technical committee. I don't think that's true at all. If we go with one of the autodetecting implementations, there's no need for a policy should; we can go straight to a list of policy musts for the required interactions between Build-Depends and build-arch. Recommending that maintainers *take advantage* of the possibility to properly split Build-Depends and Build-Depends-Indep is not really very interesting to me, once that's done. And if we want to provide a smooth transition instead, using something like Joey's proposed make-first-existing-target interface in bug #598534 (as discussed on debian-devel in http://lists.debian.org/debian-devel/2010/09/msg00704.html), we don't need this to be a policy should or must at all, because the autobuilders can then DTRT for any package whether or not it implements the build-arch target and the presence of the target merely lets us optimize build times and reduce build dependencies - so it could remain a policy may indefinitely (with some tightening of the language about how not having build-arch requires different bits to be in Build-Depends than if you do have it). I would see make-first-existing-target as a good method for easing the transition, and we could leave it a may indefinitely. But would it not be better (long-term) to aim for complete transition to requiring build-arch/build-indep for all packages (as for binary-arch/ binary-indep) and use make-first-existing-target as a useful strategy for doing the transition, but not as a long-term feature? Especially since it's a bit of a hack. Hack or not, once implemented I expect any automatic fallback handling to be with us for a while. I think it's realistic to have build-arch supported for wheezy, but I'm not sure we would want to make it mandatory even in wheezy+1, because the last packages to implement it are going to be those that also get no benefit from it. So this comes down to Policy (and the buildds) not making a large number of packages instantly buggy without good reason, and I think it's premature to worry about sunsetting make-first-existing-target before we've even started to use it. (Incidentally, if the consensus is that make-first-existing-target is a bit of a hack, then I agree with Guillem that it shouldn't be put in the make package at all, just in dpkg-buildpackage.) Unfortunately I see the same problem with this lintian check as with all the rest - if we can actually check for the existence of the target *reliably*, then we don't need to enforce its presence at all. It isn't 100% reliable (it can't be given pattern rules and includes); it gives up for dh/cdbs-using packages, but both of these handily already support the missing targets, so it's reliable enough to be useful. If the maintainer chose to use odd pattern rules, these could potentially cause a false positive. Have you tried to quantify these false positives? IME where maintainers have resisted adopting either dh or cdbs, it's usually *because* they have their own complex build systems, with pattern rules and includes, that are not straightforward to convert (if they're willing to at all). Is there any recent work on the rules checking in make which would allow dpkg-buildpackage to use the rules if present, but fall back to build if absent? This would be the most pragmatic approach, because it will both provide backwards compatibility with all older source packages, and use the rules if present in new ones. The patch is outstanding; the make maintainer is TTBOMK currently unavailable for Debian work. If there's a consensus on debian-policy/devel/ctte that we should go the make-first-existing-target route, I would be more than happy to do an NMU of make to facilitate this. As a medium-term solution it would be great if GNU make could itself support querying whether or not a makefile supports a given target. Since make needs to parse all the includes etc., only make itself can do this 100% reliably. If it's not already done, a feature request upstream would be good. 'make -qn' is already an adequate facility for this. The only disadvantage to adopting it for build-arch is that not all packages use a policy-compliant makefile for debian/rules. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer
Bug#604397: Request for TC to rule on a course of action for supporting build-arch
On Mon, Jun 06, 2011 at 09:56:22PM +0200, Andreas Barth wrote: 1) Implement support for calling 'debian/rules build-arch' in place of 'debian/rules build' by checking for the presence of the target using 'make -qn'.[1] Option 1 also implies forcing debian/rules to be a Makefile, which is think is sensible. Well, it only implies forcing debian/rules to be a makefile *if the package wants to benefit from build-arch*. $ make -f config.sub -qn build-arch; echo $? config.sub:61: *** missing separator. Stop. 2 $ That's sufficient to let dpkg-buildpackage conclude build-arch is not supported, falling back to debian/rules build, without stirring up the old arguments about whether we want to keep Policy 4.9. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#604397: Request for TC to rule on a course of action for supporting build-arch
Hi Bill, (Sending this to 629...@bugs.debian.org, which is the cloned bug actually assigned to the TC...) On Tue, Jun 07, 2011 at 12:06:18AM +0200, Bill Allombert wrote: The proposal 3) (which is implemented in dpkg as of today) was devised following a discussion in Debian policy bug #218893 as a compromise solution that was agreeable to everyone, then a patch to dpkg was written (bug #229357). For reasons beyond my control, the patch was actually merged only today. I think your read that this was a compromise solution that was agreeable to everyone is incorrect. Scott James Remnant (a dpkg maintainer at the time) raised in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=218893#345 the same objection about fragility that others have raised since. I'm actually somewhat surprised that this has been merged at all into dpkg, given that there clearly isn't agreement among the current dpkg maintainers that this is the right way forward for build-arch. During that time, two attempts to use 'make' to guess whether build-arch existed were made to dpkg and reverted because they did not work in the real world. See dpkg version 1.10.15. Given that there is zero documentation of what went wrong with the previous implementation, I give zero weight to that statement from the dpkg maintainer of the time. Aside from cases where debian/rules isn't actually a makefile, I am aware of no potential problems with the patch proposed in http://lists.debian.org/debian-devel/2007/07/msg00048.html (though I would probably write that somewhat differently today). If you can point to a specific problem with that approach, I would certainly take that into consideration, but unsubstantiated claims that an approach is impossible are equivalent to FUD. Proposal 3 is the safest approach, It is the most error-prone. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#604397: debian-policy: require build-arch and build-indep targets
On Fri, Jun 03, 2011 at 11:32:13PM -0500, Jonathan Nieder wrote: I don't think a policy should actually moves us down that road, because there's no actual penalty for not complying. The issue is *not* that maintainers don't, in general, implement this target (in fact, it's been around forever in the dh_make templates), As a counterexample, I did not implement the target in any packages I worked on unless they actually could benefit from the build-arch/build-indep distinction. There was simply no obvious reason to do it, and the documentation gave no hint that it was a good idea. The devref would be a better place to put that suggestion given the current state of things, but to say that documenting it somewhere would accomplish nothing seems like overstating things. I'm saying it won't accomplish enough to be a worthwhile intermediate step, and want us to get back to figuring out a roadmap that would enable us to turn on build-arch handling on the buildds this cycle. And if we want to provide a smooth transition instead, using something like Joey's proposed make-first-existing-target interface in bug #598534 (as discussed on debian-devel in http://lists.debian.org/debian-devel/2010/09/msg00704.html) I was about to say: without a full archive rebuild there is no guarantee that that would actually provide a smooth transition, either, since the build-arch targets are not well tested in isolation. But that was misguided of me: Assuming that the build target depends on build-arch and build-indep and does nothing for itself, the most frightening obvious case is a package that does too little in build-arch, relying on build-indep to generate some other files (e.g., manpages) that are needed for binary-arch. Typically binary-arch would depend on build in that case, so while breakage of this kind is possible, I don't imagine it would be widespread. So I'm all for this. A test rebuild would still be comforting, of course. Given that you seem to have argued in this same mail for providing both an intermediate dpkg-buildpackage switch, and introducing a Build-Options field that would have to be populated manually, I'm a little unclear: do you think make-first-existing-target is a sufficient solution for the buildds, or not? If you don't think it is, can you point to any problems with the implementation? The patch is outstanding; the make maintainer is TTBOMK currently unavailable for Debian work. If there's a consensus on debian-policy/devel/ctte that we should go the make-first-existing-target route, I would be more than happy to do an NMU of make to facilitate this. Thanks much! If you'd like, I can try out the two patches from Bug#598534 and send a comparison there. Thanks for the offer. How do you plan to try them out? Are you proposing a full-archive rebuild? By the way, shouldn't the make package be orphaned to reflect the current reality? Totally unrelated to the above, I would like to work with the maintainer to see the latest upstream version of make packaged in experimental, but for a while now the maintainer has been hard to reach. I think it would be reasonable to let the MIA team know about Manoj's protracted absence (DevRef 7.4). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#604397: debian-policy: require build-arch and build-indep targets
On Sat, Jun 04, 2011 at 04:22:43PM -0500, Jonathan Nieder wrote: Thanks much! If you'd like, I can try out the two patches from Bug#598534 and send a comparison there. Thanks for the offer. How do you plan to try them out? Are you proposing a full-archive rebuild? I am just going to try to break them. Cases like these: A. %: dh $@ B. build clean install binary-arch binary-indep binary: dh $@ .PHONY: build-arch build-indep C. something using cdbs E. ... typical debian/rules, plus: build-indep: false Ok. In that case, some of the past discussions may be informative: http://lists.debian.org/debian-devel/2007/07/msg00048.html http://lists.debian.org/debian-devel/2007/07/msg00113.html The main difference between the robustness of the implementations should be when faced with debian/rules that is not a policy-compliant makefile. Meanwhile I would be happy to see progress on the dpkg-buildpackage side. Once the pieces are together it should be possible to beg someone to do a full archive rebuild before and after hitting the switch and list packages that failed to build or whose binary packages changed in size substantially (though as mentioned before, because debian/rules binary-arch is suppposed to work on its own already, I'm not too worried about it). That part is apparently trivial, as I seem to have written a patch for it 4 years ago :-) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110604233919.gd24...@virgil.dodds.net
Bug#604397: debian-policy: require build-arch and build-indep targets
On Fri, Jun 03, 2011 at 05:09:33PM +0100, Roger Leigh wrote: Just for the record, I've implemented support in debhelper's dh command in #604563. Once applied, this will automatically add support to the huge chunk of the archive using tiny rules files. cdbs will be next on my list. debhelper 8.1.0 has such support now. Thanks! With dh and cdbs both supporting build-arch and build-indep automatically, we are now in the situation that 50% of the archive supports these rules. Is there any reason we can't now make build-arch and build-indep a should in policy? How does adding this to policy help us get to the point where we're willing to turn on use of build-arch on the buildds? I don't think a policy should actually moves us down that road, because there's no actual penalty for not complying. The issue is *not* that maintainers don't, in general, implement this target (in fact, it's been around forever in the dh_make templates), the issue is that we have no way of making use of it without a painful transition where lots of packages will FTBFS, and it's hard even to know which packages those are without trying to build them. If people want to track those packages down and NMU them today, they don't need a policy should to do so. Nor is a policy should likely to make the set of packages in need of an NMU for this any smaller. If we're willing to flip the switch on the autobuilders and force maintainers to deal with the breakage, we don't need a policy should either... we can go straight to a policy must as soon as the switch is flipped (and we should flip that switch *ASAP*, not let this question drag on any further into the release cycle). And if we want to provide a smooth transition instead, using something like Joey's proposed make-first-existing-target interface in bug #598534 (as discussed on debian-devel in http://lists.debian.org/debian-devel/2010/09/msg00704.html), we don't need this to be a policy should or must at all, because the autobuilders can then DTRT for any package whether or not it implements the build-arch target and the presence of the target merely lets us optimize build times and reduce build dependencies - so it could remain a policy may indefinitely (with some tightening of the language about how not having build-arch requires different bits to be in Build-Depends than if you do have it). 1. Providing build-arch and build-indep becomes a best practice. lintian gains a check. devref encourages the practice. I wrote a lintian check which is currently in a patch proposed as lintian bug #605012. I'm not sure if it needs to be in Policy before or after it's implemented in lintian? I thought lintian reflected policy for the most part. It probably needs a little more polish (testsuite support) before it can be applied, but the core checks are done. Unfortunately I see the same problem with this lintian check as with all the rest - if we can actually check for the existence of the target *reliably*, then we don't need to enforce its presence at all. Is there any recent work on the rules checking in make which would allow dpkg-buildpackage to use the rules if present, but fall back to build if absent? This would be the most pragmatic approach, because it will both provide backwards compatibility with all older source packages, and use the rules if present in new ones. The patch is outstanding; the make maintainer is TTBOMK currently unavailable for Debian work. If there's a consensus on debian-policy/devel/ctte that we should go the make-first-existing-target route, I would be more than happy to do an NMU of make to facilitate this. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#621833: System users: removing them
On Tue, Apr 12, 2011 at 09:31:47PM +0200, sean finney wrote: I second your original proposal though, that packages must not delete system users that they have created. I don't think anyone had objections to that, and the question is whether things should be taken further. I do object to telling maintainers they must not delete system users, without also giving guidance on how and when to lock the accounts. Sorry, no time at the moment to propose verbiage to reconcile this with your concerns. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501074903.gc11...@virgil.dodds.net
Bug#624586: Bug#618885: sasl2-bin: unowned files after purge (policy 6.8, 10.8)
On Fri, Apr 29, 2011 at 05:15:09PM +0200, Holger Levsen wrote:
On Freitag, 29. April 2011, Roberto C. Sánchez wrote:
Regardless, policy states the following in section 6.8:
5. The conffiles and any backup files (~-files, #*# files, %-files,
.dpkg-{old,new,tmp}, etc.) are removed.
Please note that /etc/sasldb2 is not a conffile. So, not removing it
should not be considered a policy violation.
Hm, right, at least on a quick search for config files I cannot find anything
in policy how config files should be treated, I can merely guess from the ucf
description that they exist...
10.7.3: If the existence of a [configuration] file is required for the
package to be sensibly configured it is the responsibility of the package
maintainer to provide maintainer scripts which correctly create, update and
maintain the file and remove it on purge.
So I don't think anything is actually missing in Policy?
(If one wishes to argue that /etc/sasldb2 is not a configuration file, then
it's also a policy violation for it to be under /etc.)
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110430083758.gb1...@virgil.dodds.net
Bug#624586: Bug#618885: sasl2-bin: unowned files after purge (policy 6.8, 10.8)
On Sat, Apr 30, 2011 at 12:02:46PM +0200, Holger Levsen wrote: On Samstag, 30. April 2011, Steve Langasek wrote: 10.7.3: If the existence of a [configuration] file is required for the package to be sensibly configured it is the responsibility of the package maintainer to provide maintainer scripts which correctly create, update and maintain the file and remove it on purge. Thanks for this pointer! So I don't think anything is actually missing in Policy? Hm, there is no link from 6.8 to 10(.7) - maybe that would be useful. 6.8 misses files described in 10.6-10.8. If you don't think such a link would be useful, I guess this bug can be closed. I don't think it's the right place for such a link; 6.8 describes the order in which actions are taken to remove and purge packages. It says nothing one way or the other about what actions the maintainer scripts are supposed to take, it's obvious to me that you need to look elsewhere in policy for this. But I'm not closing the bug, I'll leave it for a policy maintainer to decide on. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110430185952.ga12...@virgil.dodds.net
Bug#624586: Bug#618885: sasl2-bin: unowned files after purge (policy 6.8, 10.8)
On Sat, Apr 30, 2011 at 03:49:26PM -0700, Russ Allbery wrote: Steve Langasek vor...@debian.org writes: (If one wishes to argue that /etc/sasldb2 is not a configuration file, then it's also a policy violation for it to be under /etc.) It's basically similar to /etc/shadow. 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 where it's always been so moving it somewhere else would be more trouble than it's worth. For other packages like sasl (or, say, samba, which stores all its authentication databases in /var/lib/samba in Debian), neither of these arguments holds AFAICS. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110430231346.ga22...@virgil.dodds.net
Bug#621833: System users: removing them
On Sat, Apr 09, 2011 at 10:14:54AM +0100, Roger Leigh wrote: On Sat, Apr 09, 2011 at 09:44:28AM +0100, Lars Wirzenius wrote: Thus, I propose to change 9.2.2 UID and GID classes, the paragraph on uids in the range 100-999, to add the following sentence to the end of the paragraph: Packages must not remove system users and groups they have created. This does sound like a sensible addition. Will the packages be responsible for locking the accounts? I agree that the accounts should not be deleted, but that the packages should still be responsible for certain forms of cleanup: - removing the user home directory (on purge?) - locking the account - (optional) scanning the filesystem to clean up any other files owned by the user This is the good kind of cleanup to do. Deleting the account entirely is the bad kind of cleanup, because you can never guarantee that you've gotten *all* the files belonging to that user/group, thanks to removable media; so if the UID is reused, some other account gets access to files it wasn't meant to. I've always found the addition and removal of user accounts in maintainer scripts difficult, due to the huge difference in practice between packages, and the lack of detailed guidance on best practice. Would it be worth adding explicit examples of how to add system users and groups in Policy. Also, would it be worth adding support to debhelper or dpkg-maintscript-helper to do the user addition--it would unify the process so that packages won't have to reinvent the wheel, and make things much more simple and reliable. I don't think dpkg-maintscript-helper is the right layer of abstraction for something like this; we already have an imperative interface for account creation/deletion, which is adduser/deluser, and if that interface isn't sufficiently straightforward we should remedy that directly. I'm not sure if debhelper can help here. I guess we would need a new config file (debian/users?), but I'm not sure it could be done with a very debhelper-like syntax. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Patch for MultiarchCross
On Fri, Apr 08, 2011 at 07:44:27PM +0200, Goswin von Brederlow wrote: On Wed, Mar 23, 2011 at 03:05:53AM +, Wookey wrote: The Multiarch specification only covers libraries and does not specifically deal with include files. To make multiarch useful for cross-building as well as co-installation of libraries we need to install headers to /usr/include/triplet, which needs an FHS exception. Maybe we should stop calling it triplet since it isn't the gnu triplet anymore (at least for some cases)? It is still a GNU triplet; it's just not the same as the host triplet for the architecture in select cases. What could be allowed is using the new include paths with a Depends on the multiarch package even if the package itself is not multiarch. No. multiarch-support declares runtime support for ld.so. It has nothing to do with include paths (or -dev packages in general) and should not be abused like this. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Patch for MultiarchCross
On Fri, Apr 08, 2011 at 09:51:03PM +0200, Bill Allombert wrote: I already made this comment, but I strongly think it should be normative. Specifically we should mandate that: 1) /usr/include/triplet be added to the default hearder search path of triplet-gcc. It seems strange to me that we would mandate something in policy that affects approximately one package (the compiler). However, I think this is unquestionably the correct thing for the compiler to do, so if there's general agreement that it belongs in policy I'll happily second. 2) Packages that would install headers in /usr/include/path install them in /usr/include/triplet/path This is too strong a requirement. The majority of headers can still be installed to /usr/include/path because they're invariant between architectures. It's only when a header needs to contain different contents between different architectures that /usr/include/triplet must be used. Where possible, I think packages should leave their headers directly under /usr/include, because: - it reduces duplication of data on disk (but headers are small compared to libraries, so this isn't a huge deal) - while it's bad form to depend on specific filesystem paths for headers rather than using the compiler include path, there are plenty of packages in the archive whose build systems are bad form. We're in uncharted waters here, and I don't think we should make ourselves more incompatible with existing software than is strictly necessary. Requiring the user to pass -I to the compiler should be discouraged. Note that this discouragement is in conflict with the upstream behavior of a number of libraries, including much of the GNOME stack which uses pkg-config as an interface to declare additional -I arguments. So I'm not convinced putting this in policy adds much value. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Patch for MultiarchCross
On Fri, Apr 08, 2011 at 10:17:20PM +0200, Goswin von Brederlow wrote: What could be allowed is using the new include paths with a Depends on the multiarch package even if the package itself is not multiarch. No. multiarch-support declares runtime support for ld.so. It has nothing to do with include paths (or -dev packages in general) and should not be abused like this. Will there be a multiarch-dev-support then or will -dev packages have to Depends on the right versions of a number of build tools? Why do you need either? What real problem are you trying to solve? multiarch-support is needed to ensure users's systems don't render themselves completely unusable in the middle of an upgrade. multiarch-dev-support would be a lot of work to solve something that is merely an inconvenience - a compile-time error that requires the user to upgrade to the current gcc on i386 to fix. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#621479: debian-policy: retire legacy Motif policy (11.8.8)
On Thu, Apr 07, 2011 at 10:49:29AM -0700, Russ Allbery wrote: I was just looking at the incoming version of policy, and it occurred to me: is there any particular reason why there still needs to be a section in policy for The OSF/Motif and OpenMotif libraries? It defines the circumstances under which packages compiled against non-free Motif should be given names with -smotif or -dmotif suffixes; but the last such package left in the archive vanished or switched to LessTif somewhere around about Sarge. The only remaining rdeps of libmotif4 that I can see anywhere in Debian are the other members of the openmotif source package. Yeah, this whole section looks completely obsolete. I think we should just remove it entirely. Objections or seconds? Seconded. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#619186: Fix multiarch FHS exception for i386 in light of recent discussions
On Tue, Mar 29, 2011 at 05:21:59PM -0500, Jonathan Nieder wrote: Steve Langasek wrote: http://wiki.debian.org/Multiarch/Bootstrapping The current ld.so doesn't yet know about the final path (on i386), so libraries can't switch to using it or they'll fail to be found by the runtime linker. Since we don't want to wait until the next release cycle before being able to proceed to step 5, this does mean that a transitional dependency is needed to ensure a multiarch-compatible ld.so is unpacked before libraries unpack to /lib/i386-linux-gnu. [...] If you think this is important to document in policy anyway, I can prepare a patch. Yes, please. I agree with you that the normative component is already taken care of by don't be buggy, so if can be written in the informative style, that would be great. Do you mind if I split the informative text off onto a separate bug report? Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Patch for MultiarchCross
Hi there, On Wed, Mar 23, 2011 at 03:05:53AM +, Wookey wrote: The Multiarch specification only covers libraries and does not specifically deal with include files. To make multiarch useful for cross-building as well as co-installation of libraries we need to install headers to /usr/include/triplet, which needs an FHS exception. Here is a patch to policy to allow that. It could repeat most of the libraries section above but there seemed little point. I'm happy to expand it though if we think that would be helpful. I'm not sure if anything else in policy needs to be adjusted - I didn't see anything obvious. The only thing I wonder is whether we should go farther yet and make this a policy recommendation rather than just granting permission... but since we're only just now implementing toolchain support for this, I guess that might be premature. I would file this as a bug against debian-policy but I don't know whether it should be normative, informative, etc. Advice welcome. Reading the FHS carefully, I see that there is no requirement for headers to be installed *directly* under /usr/include, only that they be installed *somewhere* under this directory. And indeed, many packages create subdirectories under /usr/include already. So maybe it's not actually needed to override the FHS at all for /usr/include, until the time that we want to make this a policy recommendation? I.e., I guess this isn't a normative bug because we're not actually changing any rules; and it's not really informative either because we're not actually providing much information yet. :) Do you think there is a specific recommendation policy should make right now, or should we defer amending policy until the prelim implementation is farther along in unstable? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110402081428.gc32...@virgil.dodds.net
Re: Patch for MultiarchCross
On Wed, Mar 23, 2011 at 11:02:59AM +, Simon McVittie wrote:
On Wed, 23 Mar 2011 at 03:05:53 +, Wookey wrote:
To make multiarch useful for cross-building as well as co-installation of
libraries we need to install headers to /usr/include/triplet, which
needs an FHS exception.
Some libraries (notably GLib and D-Bus) already isolate their arch-specific
headers into a subdirectory of /usr/lib:
% dpkg -L libglib2.0-dev
...
/usr/lib/glib-2.0/include/glibconfig.h -- arch-dep (typedefs etc.)
...
/usr/include/glib-2.0/glib/gslice.h -- identical on every arch
...
The pkg-config files then cause CFLAGS to contain both
-I/usr/lib/glib-2.0/include and -I/usr/include/glib-2.0.
Under multiarch, glibconfig.h would presumably move to
/usr/lib/x86_64-linux-gnu/glib-2.0/include/glibconfig.h or whatever, along
with the rest of the contents of ${libdir}.
nod
Assuming you're not allowed to have, say, libglib2.0-dev:amd64 (= 2.28.0)
and libglib2.0-dev:armel (= 2.26.0) installed at the same time,
Yep, dpkg enforces multiarch packages to be at the same version when
configured.
these packages could be handled via the existing special cases intended
for /usr/share/doc (identical files getting refcounted).
I wouldn't say this is intended for /usr/share/doc... actually, header
files were explicitly taken into account in
https://wiki.ubuntu.com/MultiarchSpec as a relevant use case for reference
counting. :)
Making this work right would require pkg-config to look in multiarch locations
for the (current or cross) architecture; see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590992 and
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482884.
Yep. Thanks for reminding me of bug #482884, I'd completely forgotten that
this report was open!
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
Bug#620109: Policy §3.5 (on Pre-Depends) does not reflect actual practice
On Wed, Mar 30, 2011 at 01:51:40AM -0500, Jonathan Nieder wrote: Package: debian-policy Version: 3.9.1.0 Raphael Hertzog wrote[1]: It has been discussed on -release, not on -devel: http://lists.debian.org/debian-release/2011/02/threads.html#00381 (I don't think it matters much given that all important stakeholders where involved) No strong objection from me. I guess that suggests we should change policy §3.5 at the same time (to permit discussion of Pre-Depends on debian-release as an alternative to debian-devel, for example)? Actually, I was going to reply to your question with an apology and start a discussion on debian-devel about the pre-depends. I don't think debian-release is a substitute. I believe the purpose of this policy requirement is twofold. 1. get more eyeballs on the proposed change, to spot problems which the added pre-dep may cause 2. inform the wider Debian developer community about the change, so they can factor it into any plans they have for changing their *own* package relationships that might subsequently cause a problem for system upgrades. A discussion on debian-release partly satisfies the need for 1) and addresses 2) not at all. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#619186: Fix multiarch FHS exception for i386 in light of recent discussions
user debian-pol...@packages.debian.org usertags 619186 = seconded thanks If I understand the current policy process, this has met the necessary number of sign-offs (proposer + 2 seconds == 3 sign-offs), so marking as 'seconded'. Is there a policy czar available to confirm this and maybe to nudge this bug along its way? :) Note that the dpkg implementation of what's described here is imminent, so it would be good to have confirmation that it's ok on the policy side for us to use this. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
e2fsprogs as Essential: yes?
Hi folks, Currently the e2fsprogs package is marked Essential: yes in the archive. Is this a historical holdover? I believe e2fsprogs used to ship /sbin/fsck, but since 2009 (i.e., util-linux (= 2.15~rc1-1), which e2fsprogs has a pre-depends on), this has been provided by util-linux instead. The remaining programs provided by e2fsprogs are all specific to the ext* family of filesystems, so I don't think meet the definition of Essential any longer - their presence is certainly important if you have an ext[234] filesystem, but while this is the default, you can have systems that don't use ext* at all, which makes e2fsprogs no more essential in nature than the other per-filesystem fsck tools. Now that the transition to util-linux is done in a stable release, is it time for us to drop the Essential: yes flag from e2fsprogs? This will benefit those targetting embedded systems that don't use ext, where the package will be dead weight; the risk of any packages assuming availability of these e2fs-specific interfaces without a dependency is quite low; and we're at the right point in the cycle to make changes to the Essential set, where we have time to deal with any unexpected fallout. Thoughts? Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#591791: Bug#619093: splashy and systemd: error when trying to install together
Hi Michael, On Mon, Mar 21, 2011 at 11:30:06AM +0100, Michael Biebl wrote: So, in #591791 Steve proposed that packages should continue to ship sysv init script, regardless if they have a native upstart job or not, and I basically agree with that. What I don't like about the proposal in #591791 is, that each sysv init script should check itself, if it is run under upstart and exit. This means we duplicate a lot of code and add upstart specific interna to every init script shipping a native upstart job. Right, in the policy proposal I am describing that each init script is responsible for checking this. But the actual *implementation* of this check can and should use a common shell library to do the heavy lifting. Sorry, I didn't think that specifying that belonged in policy. Do you think the use of a common shell library should be enforced in policy as part of this? I'd much prefer if we could use the /lib/lsb/init-functions lib to do the same kind of redirecting for upstart. That is, all a package needs to do if it ships a native upstart job (or systemd service), is to include . /lib/lsb/init-functions in its sysv init script. lib/lsb/init-functions /would then do the correct thing, when it is run under systemd or upstart. Steve, do you think this would be an approach that works for upstart (and Ubuntu)? I hadn't thought about having /lib/lsb/init-functions automatically do this checking when sourced. I think on some level the idea offends me, the same way having C libraries call setuid() or exit() offends me. :) Also, this check is only needed for those packages that *ship* an upstart job, and surely those packages know who they are and can handle the conversion easily enough if we give them a function to call? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#619186: Fix multiarch FHS exception for i386 in light of recent discussions
Package: debian-policy Version: 3.9.1.0 Severity: normal Tags: patch User: debian-pol...@packages.debian.org Usertags: normative Hi guys, Attached is a patch to update policy's FHS exception to reflect the current consensus among the gcc, eglibc, and dpkg maintainers around the paths to use for implementation and the interface packages should use to query these paths. Cc:ing the respective maintainer mailing lists for sign-off. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org From 1f0f1281c53701e2fe549ed9f80a265ebcd9282a Mon Sep 17 00:00:00 2001 From: Steve Langasek steve.langa...@canonical.com Date: Mon, 21 Mar 2011 02:17:14 -0700 Subject: [PATCH] Fix multiarch FHS exception for i386 in light of recent discussions The current value of DEB_HOST_GNU_TYPE on i386 is unsuitable for cross-distro standardization, because it varies according to the default CPU target of the toolchain. Discussion with the toolchain and dpkg maintainers yielded an alternative solution, a new dpkg-architecture variable DEB_HOST_MULTIARCH which is committed to dpkg upstream in commit af3153d09aa3ed5597d6d415e5ab7cc3ba972e7c and will be included in the upload of dpkg 1.16.0. Update Policy to document this new requirement for multiarch. --- policy.sgml |4 ++-- upgrading-checklist.sgml |7 +++ 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/policy.sgml b/policy.sgml index 6e04c81..c708a18 100644 --- a/policy.sgml +++ b/policy.sgml @@ -6027,13 +6027,13 @@ install -m644 debian/shlibs.varpackage/var debian/varpackage/var/DEBIAN/ file/lib/vartriplet/var/file and file/usr/lib/vartriplet/var/file, where ttvartriplet/var/tt is the value returned by - ttdpkg-architecture -qDEB_HOST_GNU_TYPE/tt for the + ttdpkg-architecture -qDEB_HOST_MULTIARCH/tt for the architecture of the package. Packages may emnot/em install files to any vartriplet/var path other than the one matching the architecture of that package; for instance, an ttArchitecture: amd64/tt package containing 32-bit x86 libraries may not install these - libraries to file/usr/lib/i486-linux-gnu/file. + libraries to file/usr/lib/i386-linux-gnu/file. footnote This is necessary in order to reserve the directories for use in cross-installation of library packages from other diff --git a/upgrading-checklist.sgml b/upgrading-checklist.sgml index e696077..2138b5c 100644 --- a/upgrading-checklist.sgml +++ b/upgrading-checklist.sgml @@ -58,6 +58,13 @@ Unreleased. that install prgn/usr/bin/mailx/prgn and implement at least the POSIX-required interface. /item +tag9.1.1/tag + itemPackages installing to architecture-specific subdirectories of + file/url/lib/file must use the value returned by + prgndpkg-architecture -qDEB_HOST_MULTIARCH/prgn, not by + prgndpkg-architecture -qDEB_HOST_GNU_TYPE/prgn; this is a path change + on i386 architectures and a no-op for other architectures. + /item /taglist/p sect Version 3.9.1.0 -- 1.7.1 signature.asc Description: Digital signature
