5:24 a.m.
= 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(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
6:29 a.m.
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.
6:57 a.m.
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
9:46 a.m.
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?
> [1] https://fedorahosted.org/fpc/ticket/314
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
2:18 p.m.
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?
>
> > [1] https://fedorahosted.org/fpc/ticket/314
>
> 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
2:25 p.m.
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"
3:07 p.m.
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
3:13 p.m.
New subject: F20 System Wide Change: Change Packaging Guidelines to discourage requires into /bin and /sbin
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
3:18 p.m.
Once upon a time, Toshio Kuratomi <a.badger(a)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.
--
Chris Adams <linux(a)cmadams.net>
3:22 p.m.
New subject: F20 System Wide Change: Change Packaging Guidelines to discourage requires into /bin and /sbin
Am 16.07.2013 22:18, schrieb Chris Adams:
Once upon a time, Toshio Kuratomi <a.badger(a)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.................
3:31 p.m.
On Tue, Jul 16, 2013 at 2:22 PM, Reindl Harald <h.reindl(a)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
3:58 p.m.
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(a)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
4:15 p.m.
Once upon a time, Reindl Harald <h.reindl(a)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.
--
Chris Adams <linux(a)cmadams.net>
5:53 p.m.
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.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
3:22 p.m.
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.
10:43 a.m.
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(a)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.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
11:01 a.m.
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
3:32 a.m.
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).
--
Florian Weimer / Red Hat Product Security Team
7:14 a.m.
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.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
7:24 a.m.
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
7:40 a.m.
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.)
--
Florian Weimer / Red Hat Product Security Team
9:22 a.m.
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
12:15 a.m.
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
1:38 p.m.
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(a)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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
3998
days inactive
3999
days old
23 comments
17 participants
participants (17)
-
Adam Williamson -
Ales Kozumplik -
Björn Persson -
Chris Adams -
Christopher Meng -
Colin Walters -
Eric Smith -
Florian Weimer -
Howard Howell -
Jan Zelený -
Jaroslav Reznik -
Matthew Miller -
Reindl Harald -
Richard W.M. Jones -
Till Maas -
Toshio Kuratomi -
Vít Ondruch