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@xxxxxxxxxx> 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
Attachment:
pgp0eJR0K52Ft.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
