Hello!
On Mon, Mar 07, 2016 at 03:56:31PM +0100, Ansgar Burchardt wrote:
> Bill Allombert wrote:
> > So to recap, Marco proposal is
> >
> > diff --git a/policy.sgml b/policy.sgml
> > index 404dc73..74f0a3b 100644
> > --- a/policy.sgml
> > +++ b/policy.sgml
> > @@ -8508,6 +8508,21 @@ fi
> > renamed. If a consensus cannot be reached, <em>both</em>
> > programs must be renamed.
> > </p>
> > +
> > + <p>
> > + To support merged /usr systems, packages must not install
> a
> > + file in <file>/usr/bin</file> with the same name as a file
> in
> > + <file>/bin</file> or a file in <file>/usr/sbin</file> with
> the
> > + same name as a file in <file>/sbin</file>.
> > + If such a compatibility symlink is needed then it must be
> > + managed in the maintainer scripts in a way that will not
> break
> > + when e.g. <file>/usr/bin</file> and <file>/bin</file> are
> the
> > + same directory.
> > + Packages must not install a file in <file>/usr/lib</file>
> (or
> > + one of its subdirectories) with the same name as a file in
> > + <file>/lib</file> (or the corresponding subdirectory).
> > + </p>
> > +
> > <p>
> > Binary executables must not be statically linked with the
> GNU C
> > library, since this prevents the binary from benefiting
> from
> >
> > Who is seconding this ?
Seconded....
>
> Seconded.
>
> Though shouldn't this be worded a bit more generic? There are also
> /lib32 vs /usr/lib32 and /lib64 vs /usr/lib64 (and possibly other
> suffixes like libx32).
>
> Also I don't think Policy should require maintainer scripts for the
> implementation of compatibility symlinks. I would prefer an
> implementation-neutral wording that would allow switching to dpkg
> handling these in some declarative way without having to change Policy.
... although I also prefer some more generic wording to cover
multi-arch related directories etc. (to avoid discussions with
people who read policy by the letter), like:
>
> To support merged-<file>/usr</file> systems, packages must not
> install files in both <file>{path}</file> and
> <file>/usr/{path}</file>.
>
> In case a file gets moved between <file>{path}</file> and
> <file>/usr/{path}</file> and a compatibility symlinks is needed,
> the symlink must be managed in such a way that it will not
> break when, for example, <file>/bin</file> and <file>/usr/bin</file>
> are the same directory.
>
> Ansgar
>
(Maybe it's nice and helpful to include a hint about handling it in
maintainer scripts but at the same time I wonder if the policy document
is the right place for that given it's overly hard to update to future
best practises. Also very few packages where affected by needing this
change to begin with so hopefully extremely few new packages will
even need to take this part of policy into active consideration.)
Regards,
Andreas Henriksson
