RPM Community Forums

Mailing List Message of <rpm-users>


From: Jeff Johnson <n3npq@mac.com>
Date: Tue 28 Oct 2008 - 18:55:32 CET
Message-id: <3F0AE676-796E-443A-8961-6876C60AB07E@mac.com>

On Oct 28, 2008, at 1:35 PM, Eric MSP Veith wrote:

> Hash: SHA1
> I already learned that much. :-)
> I was interested in how RPM actually generates this implicit  
> dependency,
> especially concerning manual pages which are regular files and not  
> links.

The code that does the dirty deed is buried in lib/rpmds.c rpmdsNew.

Note lib/rpmds.c actively being extended, and not quite ready for  
or for documentation. I recently added several new types of rpmds  
objects in order to
achieve file/dir triggers, including glob patterns. My eventual goal
is to permit glob patterns with all dependencies, not just triggers,
but I need to don an asbestos suit to finish that tinkering ;-)

I do need to change the triggers write up that file paths
can now be used for triggers. That's on my doco todo++ list,
right next to your suggestions re INSTALL changes re zlib. Poke
me until I get it done please, I'm just a lazy schmuck ;-)

There's coverage testers of the functionality in rpm-5.1.6 (and  
rpm-5.2) in
tests/triggers-*.src.rpm's. Look there for examples of usage cases.

But AFAIK, there's no flaws in the rpm-5.1.6 implementation, but it
is brand spanking new, so there has been little experience with the
implementation so far (triggers are really obscure rpm functionality  

>> Exercise left to lusers to find how to disable the functionality.
>> Hint: its very not hard.
> Thanks, I know where to turn it off. Thing is: I *want* it to be  
> turned on
> and look for a way on how to create better packages. I think this is
> clearly a bug I introduced when packaging and not a fault with RPM, so
> disabling the check will cover my bug, not fix it.

Poifect! Usually I'm being asked the opposite question, how to
make rpm behave as if unchanged since originally implemented
in 1997. So try to ignore any gruffness/scrarcasm from me, its
certainly not intended personally.

Your packaging issue, if involving Filelintos dependencies, may
be conceptual. The policy that the linktos dependency is attempting to
enforce is
	All symbolic link endpoints should be in packages.
and you may not be including the package that "contains" the
end-point in your test transaction.

Usually (except for -devel symlinks) the symlink and its end-point
are in the same build.

Note also that there are certain pathologies that rpm will not get right
with linkto dependencies, particularly with complicated symlinks to  
and/or with implicit symlinks within the directory part of the path.

PLD has an example linktos pathology reported 1-2 years ago. As always,
PLD is/was the first distro to report rpm flaws. I can dig up details
for you if necessary.

I can also look at a means for disabling linktos on a per-case basis  
within a specfile if needed. But usually a modest KISS rethinking of
what your goal with symlinks is will avoid the linktos pain too.


73 de Jeff

> Thanks,
> 		-- Eric
> Version: GnuPG v1.4.9 (GNU/Linux)
> V/sAnRDLqMswMgEJlJmVFSKxQx3+7/kI
> =dxCj
> ______________________________________________________________________
> RPM Package Manager                                    http://rpm5.org
> User Communication List                             rpm-users@rpm5.org
Received on Tue Oct 28 18:56:10 2008
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.