On 02/01/2012 06:38 PM, Bill Nottingham wrote:
Panu Matilainen (pmatilai@xxxxxxxxxxxxxxx) said:
To-be-installed files obviously have no on-disk fingerprints, so it
wont work for initial installation. So yes, those "fake" compatibility
provides are needed. Strictly speaking, compatibility provides would
be needed for ALL the moved files, not just /bin, as it's technically
perfectly legal for a package to depend on an arbitrary path in
/lib[64], not just /[s]bin.
- Panu -
Would it be possible to leave out these provides and fix each individual
package to require in the new path instead?
It isn't practical to "fix" every package that requires /bin/sh.
It's not "just" that the impracticality either - not providing
/bin/sh, /sbin/ldconfig and the like would mean a huge
incompatibility break with nearly every existing package in the
wild. Not really an option.
I'm not convinced of the "all" case, though. /bin/sh, /sbin/ldconfig,
etc. could be reasonable for a package to require, and should be provided.
Requires: /lib/modules/3.1.2-1.fc16/kernel/drivers/net/3c59x.ko is likely
too dumb to live, though.
Oh, sure. Hence the "strictly speaking".
I'm not arguing for adding provides for eg /lib/modules (although I
think I've seen such dependencies in the wonderful world of kernel
module packaging ;), just pointing out that it's not 100% transparent
change for package(r)s. Made ever more fun by the rpm behavior on
installed files where you test a package on your machine, see it
installs fine and then scratch head when it fails to work as part of
initial install.
- Panu -
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
