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

[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 at redhat.com> 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/Guidelines#Filesystem_Layout>
> >> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130711/ed046668/attachment-0001.sig>