Bug#542865: Grant an FHS exception for the multiarch library directories

[Aurelien Jarno]

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  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)
>
>
>  
> +  The requirement for object files, internal binaries, and
> +  libraries, including libc.so.*, to be located
> +  directly under /lib{,32} and
> +  /usr/lib{,32} is amended, permitting files
> +  to instead be installed to
> +  /lib/triplet and
> +  /usr/lib/triplet, where
> +  triplet is the value returned by
> +  dpkg-architecture -qDEB_HOST_GNU_TYPE for the
> +  architecture of the package.  Packages may not
> +  install files to any triplet path other
> +  than the one matching the architecture of that package;
> +  for instance, an Architecture: amd64 package
> +  containing 32-bit x86 libraries may not install these
> +  libraries to /usr/lib/i486-linux-gnu.
> +  
> +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
> +multiarch.
> +  
> +
> +
> +  Applications may also use a single subdirectory under
> +  /usr/lib/triplet.
> +
> +
> +  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.
> +
> +  
> +  
> +
>The requirement that
>/usr/local/share/man be "synonymous"
>with /usr/local/man 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#543417: README.source patch system documentation requirements considered harmful

[Wouter Verhelst]

On Tue, Sep 08, 2009 at 12:48:25AM +0100, Chris Lamb wrote:
> 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.

I'm not sure I share those concerns.

In the long run, the only person whom you write documentation for is, in
fact, the newbie. The difference is only that the definition of 'newbie'
varies.

Anyone who hasn't seen a quilt-using package yet, will be helped by a
README.source that explains there's this documentation over there which
explains how quilt is supposed to be used. Anyone who hasn't seen a
Debian package yet, will be helped by the dpkg-source manpage that
explains how to run 'dpkg-source -x' to get at the source. Anyone who
hasn't used git yet, will be helped by an introductory page on how to
use it. Anyone who hasn't seen this particular package yet, will be
helped by a three-page README.source explaining how the source is laid
out.

In all the above cases, the person who's reading the documentation is a
newbie. The first is a quilt newbie; the second a Debian packaging
newbie; the third a git newbie; and the last a newbie to a particular
package.

While it might be perfectly reasonable to assume people will just read
every bit of documentation in every package that they've got installed
on every computer that they've ever used, I'd tend to think it'd be more
useful if we were to assume that isn't the case. As such, a standard
piece of documentation that explains what to do, and/or has pointers to
where the actual documentation is, is still useful -- even if it isn't
anymore to those of us who've seen it all a hundred times.

-- 
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


signature.asc
Description: Digital signature

Bug#542865: Grant an FHS exception for the multiarch library directories

[Julien Cristau]

On Fri, Sep  4, 2009 at 20:50:30 -0700, Steve Langasek wrote:

> +
> +  Applications may also use a single subdirectory under
> +  /usr/lib/triplet.
> +

Is /lib/ intentionally left out here?  I don't know how likely
that is, but if people want multiarch-compatible pam, it would have to
install modules to /lib//security?

Cheers,
Julien



-- 
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

[Steve Langasek]

On Tue, Sep 08, 2009 at 11:36:04AM +0200, Julien Cristau wrote:
> On Fri, Sep  4, 2009 at 20:50:30 -0700, Steve Langasek wrote:

> > +
> > +  Applications may also use a single subdirectory under
> > +  /usr/lib/triplet.
> > +

> Is /lib/ intentionally left out here?

Yes - the FHS doesn't grant permission to create subdirectories under /lib
currently, and our exception shouldn't go beyond what the FHS specifies.

(Whether this means /lib/security is an FHS violation... you be the judge.
:)

> I don't know how likely that is, but if people want multiarch-compatible
> pam, it would have to install modules to /lib//security?

Yes, the pam multiarch packaging branch that I have here does that. :)

-- 
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#542865: Grant an FHS exception for the multiarch library directories

[Julien Cristau]

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)
>
>
>  
> +  The requirement for object files, internal binaries, and
> +  libraries, including libc.so.*, to be located
> +  directly under /lib{,32} and
> +  /usr/lib{,32} is amended, permitting files
> +  to instead be installed to
> +  /lib/triplet and
> +  /usr/lib/triplet, where
> +  triplet is the value returned by
> +  dpkg-architecture -qDEB_HOST_GNU_TYPE for the
> +  architecture of the package.  Packages may not
> +  install files to any triplet path other
> +  than the one matching the architecture of that package;
> +  for instance, an Architecture: amd64 package
> +  containing 32-bit x86 libraries may not install these
> +  libraries to /usr/lib/i486-linux-gnu.
> +  
> +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
> +multiarch.
> +  
> +
> +
> +  Applications may also use a single subdirectory under
> +  /usr/lib/triplet.
> +
> +
> +  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.
> +
> +  
> +  
> +
>The requirement that
>/usr/local/share/man be "synonymous"
>with /usr/local/man 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

[Bernhard R. Link]

* Chris Lamb  [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

[Neil McGovern]

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
-- 
 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

[Don Armstrong]

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

[Russ Allbery]

Don Armstrong  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)   



-- 
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

[gregor herrmann]

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

[Bill Allombert]

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. 

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