Packages MUST NOT place files or directories in the /bin, /sbin, /lib or /lib64 directories

[Petr Pisar]

I've just spotted usr-move has been completed.
<https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelin...
states:

In addition, Fedora packages MUST NOT place files or directories in the
/bin, /sbin, /lib or /lib64 directories. Instead, the /usr/bin,
/usr/sbin, /usr/lib, and /usr/lib64 directories must be used.

Is that true?

Should I move /sbin/quotacheck and similar files to /usr/sbin?

Should I file bug against bash, glibc, and other packages? Or should
there be a list of exceptions?

-- Petr

[Richard W.M. Jones]

On Thu, Jul 11, 2013 at 12:48:56PM +0000, Petr Pisar wrote:
>  I've just spotted usr-move has been completed.
>
> <https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelin...
>  states:
>  
>  In addition, Fedora packages MUST NOT place files or directories in the
>  /bin, /sbin, /lib or /lib64 directories. Instead, the /usr/bin,
>  /usr/sbin, /usr/lib, and /usr/lib64 directories must be used.
>  
>  Is that true?
>  
>  Should I move /sbin/quotacheck and similar files to /usr/sbin? 
IMHO no.

>  Should I file bug against bash, glibc, and other packages? Or should
>  there be a list of exceptions? 
.. and no, we don't need a list of exceptions.

Keep it consistent with upstream / common sense / distros that
didn't make the usrmove mistake.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

[Miloslav Trmač]

On Thu, Jul 11, 2013 at 3:05 PM, Richard W.M. Jones <rjones(a)redhat.com&gt; wrote:
>  On Thu, Jul 11, 2013 at 12:48:56PM +0000, Petr Pisar wrote:
> > I've just spotted usr-move has been completed.
> >
> <https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelin...
> > states:
> >
> > In addition, Fedora packages MUST NOT place files or directories in the
> > /bin, /sbin, /lib or /lib64 directories. Instead, the /usr/bin,
> > /usr/sbin, /usr/lib, and /usr/lib64 directories must be used. 
> > Should I file bug against bash, glibc, and other packages? Or
> should
> > there be a list of exceptions?
>
>  .. and no, we don't need a list of exceptions.
>
>  Keep it consistent with upstream / common sense / distros that
>  didn't make the usrmove mistake. 
While I agree with calling this a mistake, just ignoring rules that
one doesn't like will not allow us to build even a barely consistent
distribution.  Filing bugs would be quite appropriate.

That said, I'd love Fedora to be significantly consistent in more
important matters than paths in a spec file that have exactly zero
effect on users in the best case[1].
    Mirek

[1] Note that just moving the files may not be good enough - the
package may need to add an explicit Provides:/non-usr-path and keep it
for an indefinite time.

[Toshio Kuratomi]

On Thu, Jul 11, 2013 at 03:30:11PM +0200, Miloslav Trmač wrote:
>  On Thu, Jul 11, 2013 at 3:05 PM, Richard W.M. Jones
> <rjones(a)redhat.com&gt; wrote:
>  > On Thu, Jul 11, 2013 at 12:48:56PM +0000, Petr Pisar wrote:
>  >> I've just spotted usr-move has been completed.
>  >>
> <https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelin...
>  >> states:
>  >>
>  >> In addition, Fedora packages MUST NOT place files or directories in the
>  >> /bin, /sbin, /lib or /lib64 directories. Instead, the /usr/bin,
>  >> /usr/sbin, /usr/lib, and /usr/lib64 directories must be used.
>  
>  >> Should I file bug against bash, glibc, and other packages? Or should
>  >> there be a list of exceptions?
>  > 
Yeah, I think that glibc may need an exception due to ld.so.  However, see
below.

>  > .. and no, we don't need a list of exceptions.
>  >
>  > Keep it consistent with upstream / common sense / distros that
>  > didn't make the usrmove mistake.
>  
>  While I agree with calling this a mistake, just ignoring rules that
>  one doesn't like will not allow us to build even a barely consistent
>  distribution.
>  
Yeah.

>  Filing bugs would be quite appropriate.
>   
Or make a change to either revert UsrMove or to change the guideline...
I'll talk about the latter below.

>  That said, I'd love Fedora to be significantly consistent in
> more
>  important matters than paths in a spec file that have exactly zero
>  effect on users in the best case[1].
>      Mirek
>  
>  [1] Note that just moving the files may not be good enough - the
>  package may need to add an explicit Provides:/non-usr-path and keep it
>  for an indefinite time.
>  
For moving the files themselves you should just need to modify the %files
section like this:

  %files
  -/bin/*
  +%{_bindir}/*

The question that Mirek is bringing up is what happens to everything that
references those files.  A script with a shebang line like #!/bin/sh would
work on the filesystem level due to the symlinks that are in place.  They
wouldn't work in rpm's dep handling because rpm will extract a Requires:
/bin/sh and nothing would provide it.  There's two ways to solve this:  As
Mirek says, have the package explicitly Provide: the old path.  Or patching
scripts and other references to the old path to use the new one.

The latter is invasive but technically correct.  We occassionally have to
patch other things (shebang lines that try to reference
/usr/local/bin/python, for intsance).

The former is easier... but it then makes me ask, what is the point?  If
we're thinking that the /usr/bin/sh location is more correct then we should
be patching dependents to use that location.  If we think the /bin/sh
location shouldn't be relied on (it's a legacy location... it could go away
in Fedora 5.3 * 10^10) then we must get in the habit of patching dependents
to use the new location.  On the other hand, if we think that the /bin, /lib
locations are equivalent to /usr/bin, /usr/lib, etc (and links between the
/ and /usr locations will remain forever) then that would justify continuing
to reference /bin/sh in files.  However, if the locations are really
equivalent, then there's no reason to favour one over the other in
the packaging guidelines.  So we don't even need the Provides; simply amend
the guidelines to allow both /bin and /usr/bin (and the same with the other
directories).

I'll note that this does slightly undercut one of the tenants of UsrMove --
that people won't have to guess as to which directory a file lives in; it's
always in /usr/bin.  That will still hold true for someone who is the author
of a script but it will no longer hold true for someone who is the packager
of that script as rpm dependencies will only find one of them.

Anyhow... I'm not sure of the next step -- you could open an FPC ticket and
point to this email for this rationale for changing.  The basis of my
rationale, though, might not be a correct conceptualization of UsrMove (it's
more like UsrMerge than UsrMove), so it might also belong to FESCo to rule
more precisely on that aspect.  If you open a ticket in either place, I'll
make sure that it gets routed to the right group -- it just might take
longer in one place or another.

-Toshio

[Colin Walters]

On Thu, 2013-07-11 at 07:22 -0700, Toshio Kuratomi wrote:

>  I'll note that this does slightly undercut one of the tenants of
> UsrMove --
>  that people won't have to guess as to which directory a file lives in; it's
>  always in /usr/bin.  That will still hold true for someone who is the author
>  of a script but it will no longer hold true for someone who is the packager
>  of that script as rpm dependencies will only find one of them. 
Or change rpm's dependency resolver to understand bin -> usr/bin?

[Toshio Kuratomi]

On Thu, Jul 11, 2013 at 10:46:03AM -0400, Colin Walters wrote:
>  On Thu, 2013-07-11 at 07:22 -0700, Toshio Kuratomi wrote:
>  
>  > I'll note that this does slightly undercut one of the tenants of UsrMove --
>  > that people won't have to guess as to which directory a file lives in; it's
>  > always in /usr/bin.  That will still hold true for someone who is the author
>  > of a script but it will no longer hold true for someone who is the packager
>  > of that script as rpm dependencies will only find one of them.
>  
>  Or change rpm's dependency resolver to understand bin -> usr/bin?
>   
I don't believe this is possible.  You have a symlink in one package that is
affecting the paths that are available in a separate package.  I'll let panu
or someone else on the packaging team answer in more depth if I'm wrong
about being able to do something in this area, though.

-Toshio

[Matthew Miller]

On Thu, Jul 11, 2013 at 07:22:39AM -0700, Toshio Kuratomi wrote:
>  The former is easier... but it then makes me ask, what is the point? 
> If
>  we're thinking that the /usr/bin/sh location is more correct then we should
>  be patching dependents to use that location.  If we think the /bin/sh 
Okay, so, I'm going to go out on a curmudgeonly limb and state that there is
no universe in which #!/usr/bin/sh is correct.




-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Tomas Mraz]

On Thu, 2013-07-11 at 12:28 -0400, Matthew Miller wrote: 
>  On Thu, Jul 11, 2013 at 07:22:39AM -0700, Toshio Kuratomi wrote:
>  > The former is easier... but it then makes me ask, what is the point?  If
>  > we're thinking that the /usr/bin/sh location is more correct then we should
>  > be patching dependents to use that location.  If we think the /bin/sh
>  
>  Okay, so, I'm going to go out on a curmudgeonly limb and state that there is
>  no universe in which #!/usr/bin/sh is correct. 
+1 zillion

Now we are two FESCo members, can we do something about any proposals
that would include this nonsense? :)

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb

[Sérgio Basto]

Hi,

On Qui, 2013-07-11 at 15:30 +0200, Miloslav Trmač wrote: 
>  On Thu, Jul 11, 2013 at 3:05 PM, Richard W.M. Jones
> <rjones(a)redhat.com&gt; wrote:
>  > On Thu, Jul 11, 2013 at 12:48:56PM +0000, Petr Pisar wrote:
>  >> I've just spotted usr-move has been completed.
>  >>
> <https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelin...
>  >> states:
>  >>
>  >> In addition, Fedora packages MUST NOT place files or directories in the
>  >> /bin, /sbin, /lib or /lib64 directories. Instead, the /usr/bin,
>  >> /usr/sbin, /usr/lib, and /usr/lib64 directories must be used. 
>  >> Should I file bug against bash, glibc, and other packages?
> Or should
>  >> there be a list of exceptions?
>  >
>  > .. and no, we don't need a list of exceptions.
>  >
>  > Keep it consistent with upstream / common sense / distros that
>  > didn't make the usrmove mistake. 
I don't think was a mistake , IMO to be a mistake, I need a prove that
we need /bin and /usr/bin directories as independent directories and
have some binaries in one and others in other .  


>  While I agree with calling this a mistake, just ignoring rules that
>  one doesn't like will not allow us to build even a barely consistent
>  distribution.  Filing bugs would be quite appropriate. 
>  That said, I'd love Fedora to be significantly consistent in
> more
>  important matters than paths in a spec file that have exactly zero
>  effect on users in the best case[1].
>      Mirek
>  
>  [1] Note that just moving the files may not be good enough - the
>  package may need to add an explicit Provides:/non-usr-path and keep it
>  for an indefinite time. 
IHMO , I think guideline overstate MUST NOT place files in /bin etc ,
this is applicable on scriptlets of the spec , but not in upstream code,
if upstream code use /bin, don't worry about that, because with /bin
symbol link to /usr/bin, all will be saved in /usr/bin . 

My opinion . 

-- 
Sérgio M. B.

[Reindl Harald]

Am 11.07.2013 15:05, schrieb Richard W.M. Jones:
>  On Thu, Jul 11, 2013 at 12:48:56PM +0000, Petr Pisar wrote:
> > I've just spotted usr-move has been completed.
> >
> <https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelin...
> > states:
> >
> > In addition, Fedora packages MUST NOT place files or directories in the
> > /bin, /sbin, /lib or /lib64 directories. Instead, the /usr/bin,
> > /usr/sbin, /usr/lib, and /usr/lib64 directories must be used.
> >
> > Is that true?
> >
> > Should I move /sbin/quotacheck and similar files to /usr/sbin?
>  
>  IMHO no. 
why do packaging guidelines exist then?

> > Should I file bug against bash, glibc, and other packages? Or
> should
> > there be a list of exceptions?
>  
>  .. and no, we don't need a list of exceptions. 
because there sould no one be needed

>  Keep it consistent with upstream / common sense / distros that
>  didn't make the usrmove mistake 
sorry, but this is a bad attitude

you can hadrly make as a distrubution a change, have guidelines
and then come up in public with "ignore them because i do
not like the change from a year ago"

hence, there are enough hidden packaging problems because
the guidelines are ignored from way to much packages