Bug#759492: File conflicts between /bin and /usr/bin

[Russ Allbery]

wf...@niif.hu (Ferenc Wágner) writes:
> On Sat, 31 Dec 2016 23:33:13 -0800 Russ Allbery  wrote:

>> + To support merged-/usr systems, packages must not
>> + install files in both path

> Is there a reason to omit the leading slash in this construct?  I think
> I'd find /path more symmetric and thus easier to
> follow.

Yup, I completely agree and have fixed that for 4.0.0.1.

-- 
Russ Allbery (r...@debian.org)   

Bug#759492: File conflicts between /bin and /usr/bin

[Ferenc Wágner]

On Sat, 31 Dec 2016 23:33:13 -0800 Russ Allbery  wrote:

> + To support merged-/usr systems, packages must not
> + install files in both path

Is there a reason to omit the leading slash in this construct?  I think
I'd find /path more symmetric and thus easier to
follow.
-- 
Regards,
Feri

Bug#759492: File conflicts between /bin and /usr/bin

[Russ Allbery]

Ansgar Burchardt  writes:

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

>   To support merged-/usr systems, packages must not
>   install files in both {path} and
>   /usr/{path}.

>   In case a file gets moved between {path} and 
>   /usr/{path} and a compatibility symlinks is needed,
>   the symlink must be managed in such a way that it will not
>   break when, for example, /bin and /usr/bin
>   are the same directory.

I took the liberty of tweaking this a bit when applying this patch, and
came up with the following:

--- a/policy.sgml
+++ b/policy.sgml
@@ -8634,6 +8634,22 @@ fi
  programs must be renamed.


+ To support merged-/usr systems, packages must not
+ install files in both path
+ and /usr/path.  For example, a package
+ may not install both /bin/example
+ and /usr/bin/example.
+   
+   
+ If a file is moved between path
+ and /usr/path in revisions of a Debian
+ package, and a compatibility symlink at the old path is needed,
+ the symlink must be managed in a way that will not break
+ when path
+ and /usr/path are the same underlying
+ directory due to symlinks or other mechanisms.
+   
+   
   Binary executables must not be statically linked with the GNU C
   library, since this prevents the binary from benefiting from
   fixes and improvements to the C library without being rebuilt

Now committed for the next Policy release.

-- 
Russ Allbery (r...@debian.org)   

Bug#759492: File conflicts between /bin and /usr/bin

[Felipe Sateler]

On Mon, 07 Mar 2016 15:56:31 +0100 Ansgar Burchardt  wrote:

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

I agree on both counts.

>
>   To support merged-/usr systems, packages must not
>   install files in both {path} and
>   /usr/{path}.
>
>   In case a file gets moved between {path} andÂ
>   /usr/{path} and a compatibility symlinks is needed,
>   the symlink must be managed in such a way that it will not
>   break when, for example, /bin and /usr/bin
>   are the same directory.

Seconded.

Saludos

Bug#759492: File conflicts between /bin and /usr/bin

[Raphael Hertzog]

On Mon, 07 Mar 2016, Ansgar Burchardt wrote:
> 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.
> 
>   To support merged-/usr systems, packages must not
>   install files in both {path} and
>   /usr/{path}.
> 
>   In case a file gets moved between {path} and 
>   /usr/{path} and a compatibility symlinks is needed,
>   the symlink must be managed in such a way that it will not
>   break when, for example, /bin and /usr/bin
>   are the same directory.

I also second this improved wording or any other wording in the same spirit.

I agree it's better than the initial wording. Though it would be good to
list the most common values of "{path}" (and you want to use 
path in docbook instead of {path}).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/


signature.asc
Description: PGP signature

Bug#759492: File conflicts between /bin and /usr/bin

[Andreas Henriksson]

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, both
> >       programs must be renamed.
> >     
> > +
> > +   
> > +     To support merged /usr systems, packages must not install
> a
> > +     file in /usr/bin with the same name as a file
> in
> > +     /bin or a file in /usr/sbin with
> the
> > +     same name as a file in /sbin.
> > +     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. /usr/bin and /bin are
> the
> > +     same directory.
> > +     Packages must not install a file in /usr/lib
> (or
> > +     one of its subdirectories) with the same name as a file in
> > +     /lib (or the corresponding subdirectory).
> > +   
> > +
> >     
> >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-/usr systems, packages must not
>   install files in both {path} and
>   /usr/{path}.
> 
>   In case a file gets moved between {path} and 
>   /usr/{path} and a compatibility symlinks is needed,
>   the symlink must be managed in such a way that it will not
>   break when, for example, /bin and /usr/bin
>   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

Bug#759492: File conflicts between /bin and /usr/bin

[Ansgar Burchardt]

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, both
>     programs must be renamed.
>   
> +
> + 
> +   To support merged /usr systems, packages must not install
a
> +   file in /usr/bin with the same name as a file
in
> +   /bin or a file in /usr/sbin with
the
> +   same name as a file in /sbin.
> +   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. /usr/bin and /bin are
the
> +   same directory.
> +   Packages must not install a file in /usr/lib
(or
> +   one of its subdirectories) with the same name as a file in
> +   /lib (or the corresponding subdirectory).
> + 
> +
>   
>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.

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.

  To support merged-/usr systems, packages must not
  install files in both {path} and
  /usr/{path}.

  In case a file gets moved between {path} and 
  /usr/{path} and a compatibility symlinks is needed,
  the symlink must be managed in such a way that it will not
  break when, for example, /bin and /usr/bin
  are the same directory.

Ansgar

Bug#759492: File conflicts between /bin and /usr/bin

[Raphael Hertzog]

On Sat, 05 Mar 2016, 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, both
> programs must be renamed.
>   
> +
> + 
> +   To support merged /usr systems, packages must not install a
> +   file in /usr/bin with the same name as a file in
> +   /bin or a file in /usr/sbin with the
> +   same name as a file in /sbin.
> +   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. /usr/bin and /bin are the
> +   same directory.
> +   Packages must not install a file in /usr/lib (or
> +   one of its subdirectories) with the same name as a file in
> +   /lib (or the corresponding subdirectory).
> + 
> +
>   
>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.


-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/


signature.asc
Description: PGP signature

Bug#759492: File conflicts between /bin and /usr/bin

[Bill Allombert]

On Sat, Mar 05, 2016 at 02:08:34AM +0100, Marco d'Itri wrote:
> On Jan 24, Marco d'Itri  wrote:
> 
> > > I wanted to open this discussion, but it's not clear whether we're ready
> > > yet to actually merge this patch.
> > We are now: there are less than 10 packages left which have not been 
> > fixed, all of them with patches
> We are down to 4 broken packages left (safe-rm, ksh, elvis-tiny, 
> yp-tools), none of them matter and I do not expect that the maintainers 
> will care until they will be uninstallable.
> How can we move forward with this policy change?

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, both
  programs must be renamed.

+
+   
+ To support merged /usr systems, packages must not install a
+ file in /usr/bin with the same name as a file in
+ /bin or a file in /usr/sbin with the
+ same name as a file in /sbin.
+ 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. /usr/bin and /bin are the
+ same directory.
+ Packages must not install a file in /usr/lib (or
+ one of its subdirectories) with the same name as a file in
+ /lib (or the corresponding subdirectory).
+   
+

   Binary executables must not be statically linked with the GNU C
   library, since this prevents the binary from benefiting from

Who is seconding this ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#759492: File conflicts between /bin and /usr/bin

[Marco d'Itri]

On Jan 24, Marco d'Itri  wrote:

> > I wanted to open this discussion, but it's not clear whether we're ready
> > yet to actually merge this patch.
> We are now: there are less than 10 packages left which have not been 
> fixed, all of them with patches
We are down to 4 broken packages left (safe-rm, ksh, elvis-tiny, 
yp-tools), none of them matter and I do not expect that the maintainers 
will care until they will be uninstallable.
How can we move forward with this policy change?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#759492: File conflicts between /bin and /usr/bin

[Marco d'Itri]

On Aug 27, Russ Allbery  wrote:

> I wanted to open this discussion, but it's not clear whether we're ready
> yet to actually merge this patch.
We are now: there are less than 10 packages left which have not been 
fixed, all of them with patches

I am attaching a revised text.

-- 
ciao,
Marco
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, both
 	  programs must be renamed.
 	
+
+	
+	  To support merged /usr systems, packages must not install a
+	  file in /usr/bin with the same name as a file in
+	  /bin or a file in /usr/sbin with the
+	  same name as a file in /sbin.
+	  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. /usr/bin and /bin are the
+	  same directory.
+	  Packages must not install a file in /usr/lib (or
+	  one of its subdirectories) with the same name as a file in
+	  /lib (or the corresponding subdirectory).
+	
+
 	
   Binary executables must not be statically linked with the GNU C
   library, since this prevents the binary from benefiting from


signature.asc
Description: PGP signature

Bug#759492: File conflicts between /bin and /usr/bin

[Jakub Wilk]

* Marco d'Itri , 2016-01-24, 12:27:
We are now: there are less than 10 packages left which have not been 
fixed, all of them with patches


I couldn't find bugs for these packages:

* yp-tools + hostname:
/bin/domainname
/bin/nisdomainname
/bin/ypdomainname

* pm-utils + molly-guard:
/sbin/pm-hibernate
/sbin/pm-suspend
/sbin/pm-suspend-hybrid

* elvis-tiny:
/bin/vi
(/usr/bin/vi is not shipped by any package, but managed by 
update-alternatives.)


--
Jakub Wilk

Bug#759492: File conflicts between /bin and /usr/bin

[Marco d'Itri]

On Jan 24, Jakub Wilk  wrote:

> I couldn't find bugs for these packages:
Thank you. Hopefully now that the lintian check has been merged we 
should not get many new bugs...

> * yp-tools + hostname:
I opened #812532, looks like my development/check-contents script is 
buggy since it missed this one.

> * pm-utils + molly-guard:
I opened #812535, the maintainer broke it again...

> * elvis-tiny:
> /bin/vi
> (/usr/bin/vi is not shipped by any package, but managed by
> update-alternatives.)
This is a bit of a pain because /bin/vi is a real binary which attempts 
to be clever...

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#759492: File conflicts between /bin and /usr/bin

[Marco d'Itri]

On Aug 27, Guillem Jover guil...@debian.org wrote:

 Disallowing such compatibility symlinks means that those programs
 can no longer be moved between directories w/o possibly breaking
 things that use absolute pathname, which should be considered a bug
 in Debian, but is something that still happens. And local admin
The solution is to disallow packages to *install* these symlinks, and
instead create them in postinst if needed.

I have patches for the 11 packages which need to be fixed and I will 
submit them in a few days. This is being tracked on 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=usrmerge;users=m...@linux.it

For more information about everything-in-usr please read
http://anonscm.debian.org/cgit/users/md/usrmerge.git/tree/debian/README.Debian

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#759492: File conflicts between /bin and /usr/bin

[Russ Allbery]

Package: debian-policy
Severity: wishlist

I could have sworn we already had a bug open about this, but I couldn't
find it.  If someone else does find it, please merge.

Some other distributions have merged /bin, /sbin, and /lib into /usr
via the symlinks:

/bin - /usr/bin
/sbin - /usr/sbin
/lib - /usr/lib
/lib64 - /usr/lib64

While Debian has not decided to do the same thing at this time, it's
desirable, and not particularly difficult, to support this configuration
if the local administrator wants to adopt it.  However, this requires
avoiding file conflicts between those directory pairs.

It's worthwhile to make this change even apart from this possible merge
since having two programs with the same name at different points in the
PATH is confusing.  Note that this bug does not deal with the separate
problem that Policy is not clear abot applying the rule against
conflicting binaries to binaries elsewere on the PATH (conflicts between
/usr/games/foo and /sbin/foo, for example).  I believe there is a
separate bug open about that, and we should also resolve that issue.

I wanted to open this discussion, but it's not clear whether we're ready
yet to actually merge this patch.  On my local system, I have the
following conflicts, all of which are symlinks and therefore don't pose
a functionality problem:

lrwxrwxrwx  1 root root  10 May 20  2013 chacl - /bin/chacl*
lrwxrwxrwx  1 root root  13 Feb 17  2013 dumpkeys - /bin/dumpkeys*
lrwxrwxrwx  1 root root  12 May 20  2013 getfacl - /bin/getfacl*
lrwxrwxrwx  1 root root   9 Jun  5  2013 less - /bin/less*
lrwxrwxrwx  1 root root  13 Jun  5  2013 lessecho - /bin/lessecho*
lrwxrwxrwx  1 root root  13 Jun  5  2013 lessfile - /bin/lesspipe*
lrwxrwxrwx  1 root root  12 Jun  5  2013 lesskey - /bin/lesskey*
lrwxrwxrwx  1 root root  13 Jun  5  2013 lesspipe - /bin/lesspipe*
lrwxrwxrwx  1 root root  13 Feb 17  2013 loadkeys - /bin/loadkeys*
lrwxrwxrwx  1 root root  12 May 20  2013 setfacl - /bin/setfacl*
lrwxrwxrwx  1 root root  10 Apr 12 16:34 touch - /bin/touch*
lrwxrwxrwx  1 root root  10 Jul 27  2013 which - /bin/which*

These symlinks would have to be removed to follow this new Policy rule,
which means that one of the two paths by which those programs can be
addressed would go away.  Removing, at least, /usr/bin/which would break
various packages:

http://codesearch.debian.net/search?q=%2Fusr%2Fbin%2Fwhich

We therefore may have to do something more complex or slower than this.

Anyway, for discussion purposes, here's a patch.

diff --git a/policy.sgml b/policy.sgml
index 6eac491..b00995b 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -8473,6 +8473,21 @@ fi
  renamed.  If a consensus cannot be reached, emboth/em
  programs must be renamed.
/p
+
+   p
+ Packages should not install a file in file/usr/bin/file with
+ the same name as a file in file/bin/file, a file
+ in file/usr/sbin/file with the same name as a file
+ in file/sbin/file, or a file in file/usr/lib/file with
+ the same name as a file in file/lib/file.footnote
+   This rule permits file/bin/file to be a symlink
+   to file/usr/bin/file and similarly for the other top-level
+   directories.  This is not Debian's current directory layout,
+   but it is desirable to support if the local administrator
+   wants to use it.
+ /footnote
+   /p
+
p
   Binary executables must not be statically linked with the GNU C
   library, since this prevents the binary from benefiting from

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (990, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#759492: File conflicts between /bin and /usr/bin

[Guillem Jover]

Hi!

On Wed, 2014-08-27 at 09:59:10 -0700, Russ Allbery wrote:
 Package: debian-policy
 Severity: wishlist
 
 I could have sworn we already had a bug open about this, but I couldn't
 find it.  If someone else does find it, please merge.

I'm not sure if you were thinking about #562863? Although that seems
more generic.

 It's worthwhile to make this change even apart from this possible merge
 since having two programs with the same name at different points in the
 PATH is confusing.  Note that this bug does not deal with the separate
 problem that Policy is not clear abot applying the rule against
 conflicting binaries to binaries elsewere on the PATH (conflicts between
 /usr/games/foo and /sbin/foo, for example).  I believe there is a
 separate bug open about that, and we should also resolve that issue.

It's only confusing if they are different binaries, as long as they are
just symlinks coming from the same binary package, I think it's fine
and standard practice.

 I wanted to open this discussion, but it's not clear whether we're ready
 yet to actually merge this patch.  On my local system, I have the
 following conflicts, all of which are symlinks and therefore don't pose
 a functionality problem:
 
 lrwxrwxrwx  1 root root  10 May 20  2013 chacl - /bin/chacl*
 lrwxrwxrwx  1 root root  13 Feb 17  2013 dumpkeys - /bin/dumpkeys*
 lrwxrwxrwx  1 root root  12 May 20  2013 getfacl - /bin/getfacl*
 lrwxrwxrwx  1 root root   9 Jun  5  2013 less - /bin/less*
 lrwxrwxrwx  1 root root  13 Jun  5  2013 lessecho - /bin/lessecho*
 lrwxrwxrwx  1 root root  13 Jun  5  2013 lessfile - /bin/lesspipe*
 lrwxrwxrwx  1 root root  12 Jun  5  2013 lesskey - /bin/lesskey*
 lrwxrwxrwx  1 root root  13 Jun  5  2013 lesspipe - /bin/lesspipe*
 lrwxrwxrwx  1 root root  13 Feb 17  2013 loadkeys - /bin/loadkeys*
 lrwxrwxrwx  1 root root  12 May 20  2013 setfacl - /bin/setfacl*
 lrwxrwxrwx  1 root root  10 Apr 12 16:34 touch - /bin/touch*
 lrwxrwxrwx  1 root root  10 Jul 27  2013 which - /bin/which*
 
 These symlinks would have to be removed to follow this new Policy rule,
 which means that one of the two paths by which those programs can be
 addressed would go away.  Removing, at least, /usr/bin/which would break
 various packages:

Disallowing such compatibility symlinks means that those programs
can no longer be moved between directories w/o possibly breaking
things that use absolute pathname, which should be considered a bug
in Debian, but is something that still happens. And local admin
policies might be different, so leaving some transition time is
always good.

W/o these the transitions from dpkg to GNU install-info would have
been pretty dire. Or moving update-alternatives, dpkg-divert and
dpkg-statoverride from /bin to /usr/bin. But there's many similar
examples.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org