RPM Community Forums

Mailing List Message of <rpm-devel>

Re: Problems installing the entire OS with rpm5

From: Jeff Johnson <n3npq@mac.com>
Date: Mon 26 Jan 2009 - 23:50:16 CET
Message-id: <E2EAEEF5-32BC-40B1-9F8F-5B8704601E73@mac.com>

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
> for
>> interoperating with a "native" package install, not for
> bootstrapping
>> 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
	Requires: executable(grep)
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
> dependencies
>> for ordering purposes. If you're ready to start using
> hierarchical
>> 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-
> point
>> of a symlink to be installed before the package that
> attempts
>> to create the symlink, aka "no dangling symlinks" install
> policy.
> 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  
that install
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

  • application/pkcs7-signature attachment: smime.p7s
Received on Mon Jan 26 23:50:46 2009
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.