On Jan 26, 2009, at 5:44 PM, Bernhard Rosenkränzer wrote:
> On Monday 26 January 2009 20.55:18 Jeff Johnson wrote:
>> Unsurprisingly, RPM "probe dependencies" were designed
>> interoperating with a "native" package install, not for
>> from an empty chroot.
> That's what I thought -- but I do think it would make sense to
> look through what is being installed, given rpm5 will be used
> in both contexts, and ideally without rebuilding packages
> depending on system install vs. native package install.
I'm prepared to search added package paths to satisfy
if/when the time comes. So far, you the first to even
admit to using the functionality ;-)
> For now, I've solved the problem by changing the %post
> scripts etc. to invoke grep as /bin/grep, causing a file
> dependency instead of the executable(grep) one -- that
> works in both situations assuming grep doesn't live
> somewhere else in the path (which is a safe assumption when
> talking about packages that are part of the base OS and will
> be installed along with a grep package that puts it where I
> expect it).
That likely works (but I haven't checked and can't do
depsolving in my head any more).
>> Yes. There is no attempt (atm) to use parent directory
>> for ordering purposes. If you're ready to start using
>> directory structure for ordering purposes, well, so am I (I've
>> been patiently waiting since rpm-4.4.7 for your bug report
> I sure am... And we're on 5.2 anyway, so there's no need to
> play with it on the 5.1 branch.
>> Ditto wrto filelinkto dependencies, i.e. forcing the end-
>> of a symlink to be installed before the package that
>> to create the symlink, aka "no dangling symlinks" install
> Sounds good to me -- given the dependencies are already
> there (just not used for install order), the package set should
> be ready for it.
OK, I've just checked in the dinky change needed to turn on
parentdir/linkto dependencies for package ordering purposes.
Note that I've also added a filter to give you some control
over new dependency loops.
The basic idea is to count the number of '/' characters in
the parent directory path, and use the # of slashes as a
means to filter out relations of deep paths.
The default value I've checked in is 1. Which means that packages
that install into "/bin" or "/sbin" will have a slash count of 1,
and a tsort relation for parentdirs will be added. OTOH, for packages
into "/usr/bin" or "/usr/sbin" or deeper paths, with a slash count of
2 or more, then
no additional tsort relations will be added.
See what you think. If happy with a slashDepth of 1, then try 2 => 3
=> ... 100.
Most of the benefit should be seen early, what I can't tell is whether
dependency loops suddenly cause massive install failures because of
ordering relations in new dependency loops.
73 de Jeff
Received on Mon Jan 26 23:50:46 2009
- application/pkcs7-signature attachment: smime.p7s