Bug#542865: Grant an FHS exception for the multiarch library directories
On Fri, Sep 04, 2009 at 08:50:30PM -0700, Steve Langasek wrote:
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?
Seconded.
---
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
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
signature.asc
Description: Digital signature
Bug#542865: Grant an FHS exception for the multiarch library directories
On Fri, Sep 4, 2009 at 20:50:30 -0700, Steve Langasek wrote:
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
Seconded (again).
Cheers,
Julien
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543417: README.source patch system documentation requirements considered harmful
* Chris Lamb la...@debian.org [090908 02:02]: Such phrasing will result in README.source files saying This package uses quilt, as documented in /usr/share/doc/quilt/README.source Whilst I quite like the idea of allowing source documentation to be satisfied by build dependencies, a single-line README.source still has all the drawbacks I originally filed this bug about. That is to say, the existence of your README.source file would still be a false-positive when looking at the package with respect to whether it is esoteric in some way. Raphael Geissert also argues this in #73. I think having short README.source is better than having none. If there is a short one in normal cases, people can always look at it and see at one glance whether it is what they expect or if it needs special consideration. Some bonus point is that there is a proper transition path from the old way of not having such a file. Becaus if there is a short file that says nothing special here that is a defined state and you know someone added it. If there is no file you do not know if that means nothing special here, ignore debian/patches as it is preapplied in .diff.gz or nothing special here, standard quilt patching done at build time or this package may do something special but noone has yet looked at it. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545688: debian-policy: Include webapps policy in external sub-policy documents
Package: debian-policy Severity: wishlist Hi policy folks, We've now got to the stage where we seem to have a good webapps policy in place, and would like to have it included in policy main as a 'sub-policy' document. For reference, it's at http://webapps-common.alioth.debian.org/draft/html/ Thanks, Neil -- Sp3ct0L|ZcC dou you speak frensh ? -!- Sp3ct0L|ZcC [~spec...@86.211.34.66] has quit [autokilled: This host violated network policy. If you feel an error has been made, please contact supp...@oftc.net, thanks. (2006/10/30 17.06)] signature.asc Description: Digital signature
Bug#543417: README.source patch system documentation requirements considered harmful
On Tue, 08 Sep 2009, Bernhard R. Link wrote: I think having short README.source is better than having none. If there is a short one in normal cases, people can always look at it and see at one glance whether it is what they expect or if it needs special consideration. My main concern is maintainer time spent adding and maintaining the file in many packages outstripping time saved by (as-of-yet) non-maintainers. A secondary concern is reader fatigue, where the file doesn't document anything that someone would normally already be aware of, so people ignore it in general. If we had a generic set of packaging types that we could agree didn't need to be documented in README.source (perhaps in devref, with pointers to the actual documentation?), the README.source could be reserved for things which actually were unusual, and would obviate most of the concerns raised. Don Armstrong -- THERE IS NO GRAVITY THE WORLD SUCKS -- Vietnam War Penquin Lighter http://gallery.donarmstrong.com/clippings/vietnam_there_is_no_gravity.jpg http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543417: README.source patch system documentation requirements considered harmful
Don Armstrong d...@debian.org writes: If we had a generic set of packaging types that we could agree didn't need to be documented in README.source (perhaps in devref, with pointers to the actual documentation?), the README.source could be reserved for things which actually were unusual, and would obviate most of the concerns raised. Yeah, that's where I'm coming from as well. After now having some experience with this policy, it's not feeling particularly useful to have people copy over some boilerplate if they're using quilt or dpatch in the normal and expected way. -- 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#543417: README.source patch system documentation requirements considered harmful
On Tue, 08 Sep 2009 10:31:34 -0700, Russ Allbery wrote: If we had a generic set of packaging types that we could agree didn't need to be documented in README.source (perhaps in devref, with pointers to the actual documentation?), the README.source could be reserved for things which actually were unusual, and would obviate most of the concerns raised. Yeah, that's where I'm coming from as well. After now having some experience with this policy, it's not feeling particularly useful to have people copy over some boilerplate if they're using quilt or dpatch in the normal and expected way. Count me in; these boilerplate README.source copies are tiresome for me, both for writi^Wcopying and reading (or ignoring). I also share the concern that they actually devaluate the files that contain real information (as opposed to pointing to well-known or easy-to-find docs). Cheers, gregor -- .''`. http://info.comodo.priv.at/ -- GPG Key IDs: 0x00F3CFE4, 0x8649AA06 : :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/ `. `' Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/ `-BOFH excuse #96: Vendor no longer supports the product signature.asc Description: Digital signature
Bug#543417: README.source patch system documentation requirements considered harmful
On Tue, Sep 08, 2009 at 12:48:25AM +0100, Chris Lamb wrote: Wouter Verhelst wrote: I would instead suggest changing the next paragraph to something like the following: ``In case a package uses a build system for which documentation sufficient to satisfy this requirement exists in a file installed by one of the package's build dependencies, this file should be referred to from the README.source file, rather than copied into it.'' [..] Such phrasing will result in README.source files saying This package uses quilt, as documented in /usr/share/doc/quilt/README.source Whilst I quite like the idea of allowing source documentation to be satisfied by build dependencies, a single-line README.source still has all the drawbacks I originally filed this bug about. That is to say, the existence of your README.source file would still be a false-positive when looking at the package with respect to whether it is esoteric in some way. Raphael Geissert also argues this in #73. But would such a pointer be valuable enough to mitigate these concerns? For a newbie, the answer might very well be yes. However, this seems like a weak and relatively rare case to optimise for, compounded by the high cost of excessive false-positives. It is valuable, because there are various way to use dpatch, quilt etc. in packaging, some of them let the source ready after unpacking, some of them not. A statement the package is following a specific interface is far reliable than just assuming that a build-dependency imply an interface which is not true. 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
