Bug#544981: debian-policy: Discourage native packages that are not tightly specific to Debian
Package: debian-policy Version: 3.8.3.0 Severity: wishlist Hi, Given the recent thread in debian-devel[1], I think we should document in policy that packages that are not tightly related to Debian shouldn't be native. The motivations for discouraging native packages not Debian specific are that it makes it harder for other parties to make advantage of it. For example, they would find new upstream releases that fixed Debian packaging bugs, or that were NMUs. Also, where should they report bugs? In bugs.debian.org? Native packages make sense when the package is pretty much only useful for Debian (and Debian derivatives), e.g. dpkg or apt, but not for unrelated packages. Cheers, Emilio [1] starting at http://lists.debian.org/debian-devel/2009/09/msg00079.html -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.31-rc6-686 (SMP w/2 CPU cores) Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash debian-policy depends on no packages. debian-policy recommends no packages. Versions of packages debian-policy suggests: ii doc-base 0.9.3 utilities to manage online documen -- no debconf information -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544981: debian-policy: Discourage native packages that are not tightly specific to Debian
On Fri, Sep 04 2009, Emilio Pozuelo Monfort wrote: Given the recent thread in debian-devel[1], I think we should document in policy that packages that are not tightly related to Debian shouldn't be native. This was my understanding, though I se that policy never states that explicitly. (However, policy is not exhaustive either, and things are added as the need arises). I note that the first hit for Native in policy states: --8---cut here---start-8--- Native Debian packages (i.e., packages which have been written especially for Debian) whose version numbers include dates should always use the MMDD format. --8---cut here---end---8--- Admittedly, this is in a section talking about version numbers based on dates. The motivations for discouraging native packages not Debian specific are that it makes it harder for other parties to make advantage of it. For example, they would find new upstream releases that fixed Debian packaging bugs, or that were NMUs. Also, where should they report bugs? In bugs.debian.org? Right. And what if the maintinership passes to a non-dd? Policy remarks on this in a informational footnote: --8---cut here---start-8--- [2] Although there is nothing stopping an author who is also the Debian maintainer from using this changelog for all their changes, it will have to be renamed if the Debian and upstream maintainers become different people. In such a case, however, it might be better to maintain the package as a non-native package. --8---cut here---end---8--- Native packages make sense when the package is pretty much only useful for Debian (and Debian derivatives), e.g. dpkg or apt, but not for unrelated packages. Sounds good to me. manoj -- The farther you go, the less you know. Lao Tsu, Tao Te Ching Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544981: debian-policy: Discourage native packages that are not tightly specific to Debian
On Fri, Sep 04, 2009 at 10:56:43AM +0200, Emilio Pozuelo Monfort wrote: Package: debian-policy Version: 3.8.3.0 Severity: wishlist Hi, Given the recent thread in debian-devel[1], I think we should document in policy that packages that are not tightly related to Debian shouldn't be native. The motivations for discouraging native packages not Debian specific are that it makes it harder for other parties to make advantage of it. For example, they would find new upstream releases that fixed Debian packaging bugs, or that were NMUs. Also, where should they report bugs? In bugs.debian.org? This is a false dichotomy: native Debian packages can be hosted on alioth which provides support for non-Debian users as well. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544981: debian-policy: Discourage native packages that are not tightly specific to Debian
On Fri, Sep 04, 2009 at 10:56:43AM +0200, Emilio Pozuelo Monfort wrote: Package: debian-policy Version: 3.8.3.0 Severity: wishlist Hi, Given the recent thread in debian-devel[1], I think we should document in policy that packages that are not tightly related to Debian shouldn't be native. *sigh* So I spent a whole subthread trying to explain that I think this is *not* true, and seemed to get consensus on that, and now you want to get this into policy? Gee. Whether or not a native package makes sense should be the maintainer's prerogative, not decided by policy. As I said in the thread on -devel, there can be good reasons for making a package native. E.g., the maintainer doesn't have to deal with two releases (one upstream and one for debian) for every code change, but can just do one; there is immediate use of a translation team; releases are at least tested on Debian's architectures when they are released; etc. There are also obvious downsides to doing so, and it's probably a good idea to document these somewhere (though I doubt policy is the place for that; this is more something for the devref). However, outright claiming that it should not be done, will a) make a bunch of packages insta-buggy (which is bad, as far as policy is concerned), and b) is not the right thing to do, IMO. The motivations for discouraging native packages not Debian specific are that it makes it harder for other parties to make advantage of it. While I agree that there are downsides to non-debian specific native packages, I disagree that this is a correct example: For example, they would find new upstream releases that fixed Debian packaging bugs, or that were NMUs. They can perfectly well ignore those. Also, where should they report bugs? In bugs.debian.org? Yes, why not? Native packages make sense when the package is pretty much only useful for Debian (and Debian derivatives), e.g. dpkg or apt, but not for unrelated packages. They can make sense, and it should be the maintainer's prerogative to make that decision. Having a package be a native package when it is not Debian specific does not harm either Debian or the Free Software community at large; it only influences the workflow of the Debian maintainer, and that of non-Debian packagers of the software, if any. It is okay to point out what the effect will be of making a package native, so that a maintainer knows what he's getting him- or herself into. It is not okay to force a particular workflow on a maintainer just because *you* think it's not a good workflow. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544981: debian-policy: Discourage native packages that are not tightly specific to Debian
Emilio Pozuelo Monfort po...@debian.org writes: Given the recent thread in debian-devel[1], I think we should document in policy that packages that are not tightly related to Debian shouldn't be native. The not tightly related part of that statement raises my are you sure this is Policy rather than a best practice flag. That's a rather tricky criteria to tightly define, which makes me think that Policy is not the place to talk about it. It seems more like best practice advice that would be better addressed in the devref. -- 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
Bug#544981: debian-policy: Discourage native packages that are not tightly specific to Debian
Wouter Verhelst wrote: Given the recent thread in debian-devel[1], I think we should document in policy that packages that are not tightly related to Debian shouldn't be native. *sigh* So I spent a whole subthread trying to explain that I think this is *not* true, and seemed to get consensus on that, and now you want to get this into policy? Consensus is a big word, you managed to get people agree that if maintainers really considered all the downsides even our complaints from time to time that it would be acceptable... Gee. Whether or not a native package makes sense should be the maintainer's prerogative, not decided by policy. As I said in the thread on -devel, there can be good reasons for making a package native. E.g., the maintainer doesn't have to deal with two releases (one upstream and one for debian) for every code change, but can just do one; there is immediate use of a translation team; releases are at least tested on Debian's architectures when they are released; etc. When using a non-native package, the maintainer does not have to do any separate release as the upstream tarball is in orig.tar.gz The translation team focuses on native packages (next to other Debian specific translation), because it does not have the resources to do all of it and native packages are considered Debian specific... so this is actually in some kind abusing the translation team if the package does not have to be native. The other points are also void AFAICS. There are also obvious downsides to doing so, and it's probably a good idea to document these somewhere (though I doubt policy is the place for that; this is more something for the devref). However, outright claiming that it should not be done, will a) make a bunch of packages insta-buggy (which is bad, as far as policy is concerned), and b) is not the right thing to do, IMO. They are already buggy IMHO. Also, where should they report bugs? In bugs.debian.org? Yes, why not? Sure, I don't see a problem there. It is okay to point out what the effect will be of making a package native, so that a maintainer knows what he's getting him- or herself into. It is not okay to force a particular workflow on a maintainer just because *you* think it's not a good workflow. I don't understand what the package format has to do with the work flow? Cheers Luk -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545081: dpkg-dev: dpkg-buildpackage -B should UNCONDITIONALLY invoke debian/rules build-arch
Package: dpkg-dev Version: 1.15.3.1 Severity: wishlist As is well known, dpkg-buildpackage -B does not know whether it can safely use the 'build-arch' target to debian/rules, so it always uses 'build', which makes the Build-Depends/Build-Depends-Indep distinction useless unless you bend the rules and do the build phase for your arch:all packages in binary-indep rather than build. This has been the case for nearly a decade -- 'build-arch' was introduced in Policy 3.5.6.0, released in July of 2001. There have been several proposals to fix this, either with a new Build-Options control field, or clever use of make -n, but none have achieved consensus and (as far as I know) none have made forward progress since 2007. I propose to break this multi-year deadlock by changing dpkg-buildpackage so that its -B mode UNCONDITIONALLY invokes debian/rules build-arch. Yes, this would make many packages instantly RC-buggy, but they can be fixed with a single line added to debian/rules (build-arch: build), and I contend that after eight years, we are not going to find a better solution. Let's get this done for squeeze! -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dpkg-dev depends on: ii binutils 2.19.51.20090805-1 The GNU assembler, linker and bina ii bzip2 1.0.5-3high-quality block-sorting file co ii dpkg 1.15.3.1+b1Debian package management system ii libtimedate-perl 1.1600-9 Time and date functions for Perl ii lzma 4.43-14Compression method of 7z format in ii make 3.81-6 An utility for Directing compilati ii patch 2.5.9-5Apply a diff file to an original ii perl [perl5] 5.10.0-25 Larry Wall's Practical Extraction ii perl-modules 5.10.0-25 Core Perl modules Versions of packages dpkg-dev recommends: ii build-essential 11.4 Informational list of build-essent ii gcc [c-compiler] 4:4.3.3-9 The GNU C compiler ii gcc-4.3 [c-compiler] 4.3.4-2The GNU C compiler ii gcc-4.4 [c-compiler] 4.4.1-3The GNU C compiler ii gnupg 1.4.9-4GNU privacy guard - a free PGP rep ii gpgv 1.4.9-4GNU privacy guard - signature veri Versions of packages dpkg-dev suggests: ii debian-keyring2009.05.28 GnuPG (and obsolete PGP) keys of D ii debian-maintainers1.64 GPG keys of Debian maintainers -- no debconf information -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#545081: dpkg-dev: dpkg-buildpackage -B should UNCONDITIONALLY invoke debian/rules build-arch
On Fri, Sep 4, 2009 at 1:36 PM, Raphael Hertzoghert...@debian.org wrote: forcemerge 229357 545081 thanks On Fri, 04 Sep 2009, Zack Weinberg wrote: As is well known, dpkg-buildpackage -B does not know whether it can If you knew well, you would have known that this bug already exists... it's #229357 and you're not helping us by opening a new bug report. dpkg-dev has a few dozen of open bugs, you could have looked at them before filing this one. I disagree that this is 229357. That bug is about Build-Options. This is a new proposal to *unconditionally* use build-arch in dpkg-buildpackage -B. I'm not going to play control ping-pong, but please reconsider. No, that's not the way we handle things in Debian. The most likely solution is that we're going to add a flag that maintainers can use to say that they support build-arch / build-indep. Normally I would agree with you, but there has been no visible forward motion on any such flag since 2007. build-arch has been part of policy since 200*1*. I think that the advantages of decoupling the long-stalled and independently desirable build-arch change from the going-nowhere Build-Options plans well outweigh the disadvantages of an abrupt, world-breaking transition. zw -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#542865: Grant an FHS exception for the multiarch library directories
On Fri, Aug 21, 2009 at 09:25:30PM -0700, Russ Allbery wrote:
Manoj Srivastava sriva...@debian.org writes:
On Fri, Aug 21 2009, Russ Allbery wrote:
The current restriction is specific to libraries. Don't we need to say
that you can't put *any* files into any triplet directory that isn't
for your package architecture?
Hmm. My first read was that one could not put anything that was
not a library in these directories, but perhaps it should be stated
explicitly.
I was expecting that we'd need to put anything that you might want to have
simultaneous installs from multiple architectures in that directory, which
would include, for instance, any shared library plugins or loadable
modules, which aren't strictly libraries.
We might have to duplicate some library helper programs as well, if for
instance they communicate with the library using binary structures that
are sensitive to sizeof(long).
Right, this was a bug in the proposed patch, not a deliberate statement that
only libraries belong in these directories. (As I mentioned, the first
patch was something of a trial balloon.) I think this updated patch should
cover everything for the first round.
Re-seconds?
---
policy.sgml | 34 ++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/policy.sgml b/policy.sgml
index 0bf8253..347c0bf 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -5584,6 +5584,40 @@ libbar 1 bar1 (= 1.0-1)
/item
item
p
+ The requirement for object files, internal binaries, and
+ libraries, including filelibc.so.*/file, to be located
+ directly under file/lib{,32}/file and
+ file/usr/lib{,32}/file is amended, permitting files
+ to instead be installed to
+ 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
+ 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.
+ footnote
+This is necessary in order to reserve the directories for
+use in cross-installation of library packages from other
+architectures, as part of the planned deployment of
+ttmultiarch/tt.
+ /footnote
+/p
+p
+ Applications may also use a single subdirectory under
+ file/usr/lib/vartriplet/var/file.
+/p
+p
+ The execution time linker/loader, ld*, must still be made
+ available in the existing location under /lib or /lib64
+ since this is part of the ELF ABI for the architecture.
+/p
+ /item
+ item
+p
The requirement that
file/usr/local/share/man/file be synonymous
with file/usr/local/man/file is relaxed to a
--
1.6.3.3
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#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads
On Wed, Aug 26, 2009 at 11:29:57PM -0500, Manoj Srivastava wrote: So, we should have: , | Format: | Version:= [epoch`:']upstream_version[`-'debian_revision] | Native Package NMU's: | Version =~ m/\+nmu\d+$/ | Binary Only NMU's: |Version =~ m/\+b\d+$/ ` The next tgree are tentative: , | Non-native package NMU: |Version =~ m/\-\.\d+$/ ` This is tentative since I can't see why we need to outlaw packages adding \+nmu\d+ even on non-native packages. Perhaps policy should butt out here, if the pattern is different for non-native NMU's than for Native package NMU's. Thus far, consistent with current practice. , | Stable Security NMU's |Version =~ m/\+deb\d\d.\d+$/ | Testing Security NMU's | Version =~ m/\+debt\d\d.\d+$/ ` These last two do not have buy in from the security team, as far as I can tell. Right, since they're not actually being used by the security team I don't think there's anything to be gained by declaring in policy that the security team /should/ use 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#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads
On Tue, Sep 01, 2009 at 11:14:04PM +0200, Julien Cristau wrote:
On Tue, Sep 1, 2009 at 14:06:17 -0700, Steve Langasek wrote:
On Tue, Sep 01, 2009 at 11:39:40AM +0200, Julien Cristau wrote:
On Sun, Aug 30, 2009 at 23:38:17 +0200, Lucas Nussbaum wrote:
That's unfortunate. Imagine the following scenario:
1. Package P is released in sarge, with version 1.0-1.
2. Package P is installed on a system S, running sarge.
3. etch is released with P 1.0-1.
4. A security bug is found in P.
Does this actually happen? How often?
Often enough that it's been discussed repeatedly over the years; not often
enough that anyone has fixed it. :)
Every time I've seen it discussed, it was by people who aren't part of
the security team, and so far the security team seem to say it's not a
concern for them, so for all I know it may just be theoretical…
Binary packages with the exact same version between etch and lenny:
$ zgrep -h Filename dists/{etch,lenny}/main/binary-i386/Packages.gz | sort |
uniq -d | wc -l
1838
$
Source packages at the same version between etch and lenny (which may
include source packages that have been incremented only by a binNMU
version):
$ zgrep -h ' .*\.dsc' dists/{etch,lenny}/main/source/Sources.gz | sort | uniq
-d | wc -l
1630
$
This represents roughly 10% of the binaries in main, and roughly 16% of the
sources.
$ for src in $(
zgrep -h ' .*\.dsc' ../../dists/{etch,lenny}/main/source/Sources.gz |
sort | uniq -d | sed -e's/.* //; s/_.*//'
); do
zcat dists/lenny/updates/main/source/Sources.gz |
grep-dctrl -FPackage -sPackage -X $src
done
$
So no actual source packages that have had this problem for etch and lenny,
interestingly enough.
I thought there had been one in the sarge timeframe; but I'm not going to go
digging any farther to confirm this. Yes, the problem is more or less
theoretical.
--
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
