#314 proposed packaging guidelines change: https://fedoraproject.org/wiki/User:Akozumpl/No_bin_deps
Closed: Fixed None Opened 10 years ago by akozumpl.

No Description Provided


Seems like a "just do it" kind of thing to me. +1 in any case, though I guess EPEL might need to carry a note about the difference in binary locations.

This is the wrong way to go about it, IMO. yum/dnf just use text, so anyone expecting /bin/foo to match /usr/bin/foo can take a long walk off a short pier.

On the other side a lot of packages are still providing their binaries as /bin/foo (cpio, dbus, dash, zsh, etc. etc.) ... so saying that requiring packages aren't allowed to use /bin/foo seems counter intuitive. If we want to we could say that no package is allowed to have anything install into /bin/foo anymore, and maybe have someone file bugs for that.

Well, saying you can't have /bin/X dependencies I guess is only half of the problem. The real issue is that we have two ways to name the binaries, and no easy well to tell what way any particular package chose. Yet you have to know, and get it right, if you want to reference a binary in a dependency.

Also at issue is scripts; surely we don't want to ban #!/bin/sh (or mandate changing it everywhere) but I doubt RPM will automatically convert that to a dependency on /usr/bin/sh. But at least for manual dependencies, taking /bin out of the list gets us a step closer.

I would also note that even if we do that, and all our packages comply, a lot of good packages will provide the /bin/ variants (like bash manually provides /bin/sh and /bin/bash) and we aren't going to make anybody happy if they are required to "fix" their (portable to everything in the world) scripts from using "#! /bin/foo" to "#! /usr/bin/foo" just to comply with a policy.

Which is mostly what tibbs said :).

-1

I was hoping that someone would propose something close to the opposite in the near future, explicitly allowing packagers to choose whether the /bin/ or /usr/bin/ location is the canonical location of the file:
https://lists.fedoraproject.org/pipermail/devel/2013-July/185153.html

The basic problem is that packages are going to have things like scripts with #!/bin/sh shebang lines. Rpm auto dep extraction will turn this into a requirement for /bin/sh. Unless we mandate that all of these have to be patched to use #!/usr/bin/sh instead, the autodeps will be broken if the bash package switches to use /usr/bin/sh in its %files. So at this level, the packager should be able to choose whether the location for deps to resolve makes more sense in /bin/ or /usr/bin/.

The ramification for this proposed change are that explicit Requires need to choose the same file location as the packager chose. If the bash package specifies /bin/sh as the dep location then an explicit Requires would need to use Requires: /bin/sh.

I would be willing to change my -1 vote if we discuss this root problem and decide that, indeed, packagers are required to patch everything to use /usr/bin and /usr/sbin instead of /bin and /sbin.

Replying to [comment:2 james]:

If we want to we could say that no package is allowed to have anything install into /bin/foo anymore, and maybe have someone file bugs for that.

We already do:

https://fedoraproject.org/wiki/Packaging:Guidelines#Filesystem_Layout

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. Packages must assume that /bin, /sbin, /lib, and /lib64 are symbolic links to the /usr/bin, /usr/sbin, /usr/lib, and /usr/lib64 directories, respectively.

But even though I may have written that and I'm even more sure that I voted for it, I think I've changed my mind. Rather than asserting /usr/bin is the canonical location, it would be much better to treat /bin/ and /usr/bin/ as both containing the same files. Packagers are allowed to specify which location is the canonical location for the files they're packaging for dependency purposes. Packagers which depend on those files will have to sort it out or use a package dep instead of a file dep. As noted in my email, we may want to run this by fesco as well -- it's not really a change in fesco policy but is a different interpretation of the UsrMove Feature so even just a heads up would probably be good.

I don't really want to sink deep into this discussion but the fact is UsrMove is a thing that a) should never have happened b) has never been seen through. UsrMove is what set us out on a way of distro incompatibility.

The change proposed here is only trying to tidy up one particular area of the mess left behind. The decision to forbid packages to install into /bin etc. was similar one and a good one. Also, obviously, we can not make /usr/bin/bash etc. shebangs mandatory right now, but we should make it a part of the guideline that we won't enforce at first so the right changes can start happening.

Please go ahead with the change I'm proposing.

So in today's fesco, I stated what I think is the underlying issue like this: Does the UsrMove feature mean that we've replaced /bin with /usr/bin or that we've merged /bin with /usr/bin. FESCo stated a preference for thinking of it as a merge rather than a replacement.

With that in mind, I would propose the following:

1) Remove the prohibition of using /bin, /sbin, /lib or /lib64 in https://fedoraproject.org/wiki/Packaging:Guidelines#Filesystem_Layout

2) We could write something like this in its place:

https://fedoraproject.org/wiki/User:Toshio/Effect_of_UsrMove

Replying to [comment:8 toshio]:

So in today's fesco, I stated what I think is the underlying issue like this: Does the UsrMove feature mean that we've replaced /bin with /usr/bin or that we've merged /bin with /usr/bin. FESCo stated a preference for thinking of it as a merge rather than a replacement.

"FESCo stated a preference for thinking." That is so cute.

1) Remove the prohibition of using /bin, /sbin, /lib or /lib64 in https://fedoraproject.org/wiki/Packaging:Guidelines#Filesystem_Layout

That's a bad idea, it goes backwards against UsrMove. If we want to move backwards from UsrMove then let's just revert it completely not make it even more braindead. If someone puts something in /bin then how do people Require: it in a spec? they won't be able to do Requires: /bin/that knowing there's no /bin really. By requiring /usr/bin/that the dep resolving will fail as nothing provides /usr/bin/that. It will even make the spec less distro agnostic.

2) We could write something like this in its place:

https://fedoraproject.org/wiki/User:Toshio/Effect_of_UsrMove

I think the bash maintainer already knows he should Provide: /bin/bash for now. Mostly everybody else should use /usr/bin.

Replying to [comment:9 akozumpl]:

If someone puts something in /bin then how do people Require: it in a spec? they won't be able to do Requires: /bin/that knowing there's no /bin really.

Requires: /bin/that should work in this case. Do you know something I don't?

That's why I proposed to create a fixed (not set in stone but as little changing as possible) list of packages that are allowed to install in /bin /lib ... whatever because they were always installing there and other packages expect them to be like that and the rest of the Fedora packages would be required to use /usr/...

This would avoid unnecessarily work such as completely nonsensical replacement of /bin/sh with /usr/bin/sh in shebangs but made the situation clear enough.

Also the list might be as small as to contain only glibc and bash perhaps.

https://fedoraproject.org/wiki/User:Toshio/Effect_of_UsrMove approved as replacement for ban on /bin /sbin /lib* files. (+1:7, 0:0, -1:0)

Draft has been written into the Guidelines.

Announcement text:

The prohibition against packages installing files into /bin, /sbin, /lib, and /lib4 has been removed and a section explaining how Fedora's UsrMove feature interacts with the rpm %files section has been added. Packagers who maintain software that installs into /bin, /sbin, /lib, and /lib64 historically or in upstream are encouraged to read that sectionto understand what's best for their package: https://fedoraproject.org/wiki/Packaging:Guidelines#Effect_of_the_UsrMove_Fedora_Feature

Login to comment on this ticket.

Metadata