= Proposed System Wide Change: Change Packaging Guidelines to discourage requires into /bin and /sbin = https://fedoraproject.org/wiki/Changes/NoBinDeps
Change owner(s): Ales Kozumplik ales@redhat.com
Disallow dependencies on files under /bin, /sbin, /lib and /lib64.
== Detailed description == The current packaging guidelines read:
"Whenever possible you should avoid file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin."
I propose changing this to:
"Whenever possible you should avoid file dependencies outside of /etc, /usr/bin, or /usr/sbin."
Related FPC ticket [1]: FPC wanted this change to be created.
== Scope == Proposal owners: None Other developers: replace all explicit /bin/<foo> requires with /usr/bin/<foo>.
Release engineering: N/A Policies and guidelines: update the packaging guidelines accordingly.
[1] https://fedorahosted.org/fpc/ticket/314 _______________________________________________ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
Sounds great.
But I think a lot of packages have relationship with icon cache need to be updated. Do we need to fix it by automated script or let packagers finish?
Thanks.
Related FPC ticket [1]: FPC wanted this change to be created.
Oh really?
In that ticket I see one FPC member being for and two being against the change.
Björn Persson
On 16. 7. 2013 at 13:57:02, Björn Persson wrote:
Related FPC ticket [1]: FPC wanted this change to be created.
Oh really?
In that ticket I see one FPC member being for and two being against the change.
Yeah, the original message from Ales was incorrect. It was FESCO that recommended this change to be created so it can be discussed more widely. We certainly don't want to go around FPC or anything.
Note that we don't necessarily insist on this change to be implemented. Ales was just pointing out that there is a potential problem caused by leftovers of /usr move. What to do with the information is up to you.
Thanks Jan
On Tue, Jul 16, 2013 at 04:46:26PM +0200, Jan Zelený wrote:
On 16. 7. 2013 at 13:57:02, Björn Persson wrote:
Related FPC ticket [1]: FPC wanted this change to be created.
Oh really?
In that ticket I see one FPC member being for and two being against the change.
Yeah, the original message from Ales was incorrect. It was FESCO that recommended this change to be created so it can be discussed more widely. We certainly don't want to go around FPC or anything.
With my FPC hat on, thanks!
Note that we don't necessarily insist on this change to be implemented. Ales was just pointing out that there is a potential problem caused by leftovers of /usr move. What to do with the information is up to you.
<nod> I think that the best course of action would to rethink UsrMove as UsrMerge which I would then take to the rest of the FPC as getting rid of the prohibition on packages listing /bin, /sbin/ lib, /lib64 as the location in the file. The caveats of package maintainers having to think in terms of the dependencies and canonical locations instead of whether it was symlinked on the path on their own system would still apply.
Posible alternatives for FPC to consider if FESCo decides we really want to think in terms of /usr/{bin,sbin,[..]} being the canonical correct place and in the distant future, /bin might go away:
* Have package maintainers patch upstreams to use /usr/{bin,lib,[..]} instead of /{bin,lib[...]} (for instance, shebang lines) * Have packages which traditionally provide /{bin,sbin,possibly lib but I can't think of something in /lib that's actually causing breakage} create Virtual Provides for those older file paths. (Note: This could also be done in the case of thinking of things in terms of a merge instead of a move but it wouldn't be as needed as most upstreams will simply work out of the box if default values are used for both the package providing the file in /{bin,sbin,[...]} ) and the package using those files. * Possibly create an exception list to go along with either of these alternatives. For instance, I know someone mentioned moving the dynamic loader out of /lib{,64} would be an extraordinarily bad idea (OTOH, I don't think rpm dependencies embed the fully pathed dynamic linker so this may not be a concern).
FPC alternatives if FESCo were to decide that UsrMove was a mistake and should be reverted:
* FPC would remove the prohibition from packages listing files in /{bin,sbin,[...]} * Guidelines would be checked to be sure that references to programs used the correct path.
-Toshio
Am 16.07.2013 21:18, schrieb Toshio Kuratomi:
<nod> I think that the best course of action would to rethink UsrMove as UsrMerge which I would then take to the rest of the FPC as getting rid of the prohibition on packages listing /bin, /sbin/ lib, /lib64 as the location in the file. The caveats of package maintainers having to think in terms of the dependencies and canonical locations instead of whether it was symlinked on the path on their own system would still apply.
Posible alternatives for FPC to consider if FESCo decides we really want to think in terms of /usr/{bin,sbin,[..]} being the canonical correct place and in the distant future, /bin might go away:
- Have package maintainers patch upstreams to use /usr/{bin,lib,[..]}
instead of /{bin,lib[...]} (for instance, shebang lines)
if UsrMove would have been planned properly RPM/rpmbuild would have the capabilities ot fix this at the buildtime instead insist that anybody rewrites and patches anything
the current state is the result of "well, we propose the feature and somewhere in time we fix leftovers" which should not have happened if FESCo would have learned from F15/systemd
the difference in "making mistakes and learn" and "repeat the mistakes"
On Tue, Jul 16, 2013 at 09:25:37PM +0200, Reindl Harald wrote:
Am 16.07.2013 21:18, schrieb Toshio Kuratomi:
<nod> I think that the best course of action would to rethink UsrMove as UsrMerge which I would then take to the rest of the FPC as getting rid of the prohibition on packages listing /bin, /sbin/ lib, /lib64 as the location in the file. The caveats of package maintainers having to think in terms of the dependencies and canonical locations instead of whether it was symlinked on the path on their own system would still apply.
Posible alternatives for FPC to consider if FESCo decides we really want to think in terms of /usr/{bin,sbin,[..]} being the canonical correct place and in the distant future, /bin might go away:
- Have package maintainers patch upstreams to use /usr/{bin,lib,[..]}
instead of /{bin,lib[...]} (for instance, shebang lines)
if UsrMove would have been planned properly RPM/rpmbuild would have the capabilities ot fix this at the buildtime instead insist that anybody rewrites and patches anything
This is not a rpm or rpmbuild issue.
-Toshio
Am 16.07.2013 22:07, schrieb Toshio Kuratomi:
On Tue, Jul 16, 2013 at 09:25:37PM +0200, Reindl Harald wrote:
Am 16.07.2013 21:18, schrieb Toshio Kuratomi:
<nod> I think that the best course of action would to rethink UsrMove as UsrMerge which I would then take to the rest of the FPC as getting rid of the prohibition on packages listing /bin, /sbin/ lib, /lib64 as the location in the file. The caveats of package maintainers having to think in terms of the dependencies and canonical locations instead of whether it was symlinked on the path on their own system would still apply.
Posible alternatives for FPC to consider if FESCo decides we really want to think in terms of /usr/{bin,sbin,[..]} being the canonical correct place and in the distant future, /bin might go away:
- Have package maintainers patch upstreams to use /usr/{bin,lib,[..]}
instead of /{bin,lib[...]} (for instance, shebang lines)
if UsrMove would have been planned properly RPM/rpmbuild would have the capabilities ot fix this at the buildtime instead insist that anybody rewrites and patches anything
This is not a rpm or rpmbuild issue
tell that yum and RPM with *repeatly* broken deps of packages which used "/usr/sbin/ldconfig" what is the *correct* real path after UsrMove and made more than once troubles at a random time
translate "Requires: /bin/whatever" to "Requires: /usr/bin/whatever" translate "Provides: /bin/whatever" to "Provides: /usr/bin/whatever"
and you are done for a lot of cases ______________________
i have the following in a meta-package on any machine since a year and all this troubles have stopped from one moment to the next which must not be needed on a overall consistent environment
Provides: /bin/perl Provides: /usr/sbin/ldconfig
Once upon a time, Toshio Kuratomi a.badger@gmail.com said:
- Have package maintainers patch upstreams to use /usr/{bin,lib,[..]} instead of /{bin,lib[...]} (for instance, shebang lines)
#!/bin/sh is the cannonical first line for a Bourne(-compatible) shell script, and nothing should change that. Even on other Unix OSes with a /bin->/usr/bin symlink, all the shell scripts referenced /bin/sh.
Am 16.07.2013 22:18, schrieb Chris Adams:
Once upon a time, Toshio Kuratomi a.badger@gmail.com said:
- Have package maintainers patch upstreams to use /usr/{bin,lib,[..]} instead of /{bin,lib[...]} (for instance, shebang lines)
#!/bin/sh is the cannonical first line for a Bourne(-compatible) shell script, and nothing should change that. Even on other Unix OSes with a /bin->/usr/bin symlink, all the shell scripts referenced /bin/sh
/bin/sh is *not* a bash script /bin/sh is *whatever* your default shell would be
/bin/bash would be the first line of a *bash*-script
if you work with your bash-scripts on a machine where „/bin/sh“ -> „bash“ is „/bin/sh“ -> „dash“ you would notice the difference.................
On Tue, Jul 16, 2013 at 2:22 PM, Reindl Harald h.reindl@thelounge.net wrote:
/bin/sh is *not* a bash script /bin/sh is *whatever* your default shell would be
I certainly hope not. I've worked on plenty of Unix machines where the default shell was csh or tcsh, but if /bin/sh had been csh or a link to it, all hell would have broken loose.
/bin/sh had bloody well better be something that is compatible with the Bourne shell.
Eric
On Tue, 2013-07-16 at 14:31 -0600, Eric Smith wrote:
On Tue, Jul 16, 2013 at 2:22 PM, Reindl Harald h.reindl@thelounge.net wrote:
/bin/sh is *not* a bash script /bin/sh is *whatever* your default shell would be
I certainly hope not. I've worked on plenty of Unix machines where the default shell was csh or tcsh, but if /bin/sh had been csh or a link to it, all hell would have broken loose.
/bin/sh had bloody well better be something that is compatible with the Bourne shell.
Eric
On F17, and on the last solaris I used (5 years ago), /bin/sh was a link and has been one for many years in Unix land. For example on my system right now:
ls -al /bin/sh lrwxrwxrwx. 1 root root 4 Mar 18 11:28 /bin/sh -> bash
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
Am 16.07.2013 22:18, schrieb Chris Adams:
#!/bin/sh is the cannonical first line for a Bourne(-compatible) shell script, and nothing should change that. Even on other Unix OSes with a /bin->/usr/bin symlink, all the shell scripts referenced /bin/sh
/bin/sh is *not* a bash script
I said nothing about bash.
/bin/sh is *whatever* your default shell would be
No, /bin/sh is a Bourne compatible shell. Your default shell may be bash, ksh, tcsh, etc., not all of which are Bourne compatible. /bin/sh is a Bourne-compatible shell for running scripts.
On Tue, Jul 16, 2013 at 10:22:01PM +0200, Reindl Harald wrote:
/bin/sh is *not* a bash script /bin/sh is *whatever* your default shell would be
Says who or what? I think we're _probably_ striving to be functionally compatible with the Posix standard whereby 'sh' follows this specification: http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html
That's not bash, but bash does in fact strive to be (at least mostly) compatible when called as sh.
By that standard, by the way, the location doesn't need to be fixed at /bin/sh. But, I think we'd be doing some seriously quixotic work to patch everything for a pretty low return.
On Tue, 2013-07-16 at 12:18 -0700, Toshio Kuratomi wrote:
<nod> I think that the best course of action would to rethink UsrMove as UsrMerge which I would then take to the rest of the FPC as getting rid of the prohibition on packages listing /bin, /sbin/ lib, /lib64 as the location in the file.
Yes.
- Have package maintainers patch upstreams to use /usr/{bin,lib,[..]} instead of /{bin,lib[...]} (for instance, shebang lines)
This is extreme, almost entirely pointless busywork. The cost of the /bin -> usr/bin symbolic link on the filesystem is very very small. Let me phrase it this way: I doubt anyone can come up with a workload where the symlink traversal is a measurable part of a real application. Particularly when compared to the other inefficiencies and outright buggy crap[1] in the vast swaths of even core userspace.
- Have packages which traditionally provide /{bin,sbin,possibly lib but I can't think of something in /lib that's actually causing breakage} create Virtual Provides for those older file paths.
Or again, have RPM synthesize them automatically if the build environment has that magical rpmlib(X-Something) that I can't find in a quick search.
[1] Some of that buggy crap is my code; it makes more sense for me to spend scarce engineering time on fixing issues that affect actual real world scenarios than to go on a global search and replace for /bin -> /usr/bin and dealing with the fallout when I later need to backport something to RHEL6 for example. Same applies to everyone else.
On Tue, Jul 16, 2013 at 12:24:17PM +0200, Jaroslav Reznik wrote:
= Proposed System Wide Change: Change Packaging Guidelines to discourage requires into /bin and /sbin = https://fedoraproject.org/wiki/Changes/NoBinDeps
Change owner(s): Ales Kozumplik ales@redhat.com
Disallow dependencies on files under /bin, /sbin, /lib and /lib64.
It would probably be a good idea to change this proposal to explain why you want to make this change (rather than having everyone follow an obscure FPC link). ie. That dependencies on /bin etc don't work.
Rich.
On Tue, Jul 16, 2013 at 12:24:17PM +0200, Jaroslav Reznik wrote:
= Proposed System Wide Change: Change Packaging Guidelines to discourage requires into /bin and /sbin = https://fedoraproject.org/wiki/Changes/NoBinDeps
== Scope == Proposal owners: None Other developers: replace all explicit /bin/<foo> requires with /usr/bin/<foo>.
IMHO it would be nicer if there was a rough estimate about how many packages are affected. Also it might be more efficient to just let provenpackagers do this for everyone who does not want to do it.
Regards Till
On 07/16/2013 06:01 PM, Till Maas wrote:
On Tue, Jul 16, 2013 at 12:24:17PM +0200, Jaroslav Reznik wrote:
= Proposed System Wide Change: Change Packaging Guidelines to discourage requires into /bin and /sbin = https://fedoraproject.org/wiki/Changes/NoBinDeps
== Scope == Proposal owners: None Other developers: replace all explicit /bin/<foo> requires with /usr/bin/<foo>.
IMHO it would be nicer if there was a rough estimate about how many packages are affected. Also it might be more efficient to just let provenpackagers do this for everyone who does not want to do it.
In rawhide/x86_64, including /bin/sh and /bin/bash, 4241 source packages are affected (out of 13912). With an exception for /bin/sh and /bin/bash, we are down to 66 source packages (attached, listing binary package NEVRA and required capability).
On Wed, Jul 17, 2013 at 10:32:15AM +0200, Florian Weimer wrote:
libguestfs-tools-c-1:1.23.8-5.fc20.x86_64,/bin/vi
Fixed (in git). What I don't understand is why this didn't give a broken dependency? I must have installed this package hundreds of times on dozens of systems, and I've never seen it complain about /bin/vi being missing/broken/not available.
Rich.
Am 17.07.2013 14:14, schrieb Richard W.M. Jones:
On Wed, Jul 17, 2013 at 10:32:15AM +0200, Florian Weimer wrote:
libguestfs-tools-c-1:1.23.8-5.fc20.x86_64,/bin/vi
Fixed (in git). What I don't understand is why this didn't give a broken dependency? I must have installed this package hundreds of times on dozens of systems, and I've never seen it complain about /bin/vi being missing/broken/not available.
it happens only if the other package get updated as well as "Requires: /usr/sbin/ldconfig" only hit you due a glibc-update which does only "Provides: /sbin/ldconfig" and this is satisfied by the symlinks on the rootfs because *both* exists, but it makes troubles on updates of the packages which provides the other way
that is why the unfinished UsrMove is such a unpredictable thing
On 07/17/2013 02:14 PM, Richard W.M. Jones wrote:
On Wed, Jul 17, 2013 at 10:32:15AM +0200, Florian Weimer wrote:
libguestfs-tools-c-1:1.23.8-5.fc20.x86_64,/bin/vi
Fixed (in git). What I don't understand is why this didn't give a broken dependency? I must have installed this package hundreds of times on dozens of systems, and I've never seen it complain about /bin/vi being missing/broken/not available.
vim-minimal provides /bin/vi, presumably not to break its reverse dependencies. (Historically, /bin/vi is the correct path.)
Dne 17.7.2013 10:32, Florian Weimer napsal(a):
rubygem-apipie-rails-0.0.21-1.fc19.noarch,/bin/env
Seems to be dead code. I notified upstream about it:
https://github.com/Pajk/apipie-rails/issues/135
Vít
I don't really appreciate the discussion this has started. All I had to say about this is summed up here:
https://fedorahosted.org/fpc/ticket/314#comment:7
From a position of someone who works on packaging tools and someone who clashed with UsrMove several times already, this is my best shot at making Fedora a bit less broken. I won't waste any more time on this though: if the opinion of the "expert masses" and FESCO is against, you won't hear me arguing for this twice. How can we expect the same decision process that gets us break things with each new release to be able to fix them?
Ales
On Tue, 2013-07-16 at 12:24 +0200, Jaroslav Reznik wrote:
= Proposed System Wide Change: Change Packaging Guidelines to discourage requires into /bin and /sbin = https://fedoraproject.org/wiki/Changes/NoBinDeps
Change owner(s): Ales Kozumplik ales@redhat.com
On the face of it, calling this a Change seems bizarre. The functionality in question is entirely 'packaging bureaucracy'. It is not user facing in any way. The change does nothing at all to improve (or worsen) the Fedora user experience. It's purely an issue of packaging rules. What is the point of running it through the Change process? FPC can refer a decision to FESCo for discussion without misusing the Change process.