RPM Community Forums

Mailing List Message of <rpm-users>


From: Jeff Johnson <n3npq@mac.com>
Date: Wed 29 Oct 2008 - 02:21:33 CET
Message-id: <4416320F-B798-4536-A84A-D53755C86EF3@mac.com>

On Oct 28, 2008, at 9:02 PM, Eric MSP Veith wrote:

> Hash: SHA1
> Hey,
> On Tuesday 28 October 2008, Jeff Johnson <n3npq@mac.com> wrote:
>> 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.
> Ok, I'll look into it when I find the time, thanks for that hint. I  
> guess
> the rpmdsNew(...) function is a good place to start when creating new
> implicit dependency generators?
> A propos dependencies: How can I add new (explicit) dependency  
> generators
> without messing to much around with the RPM sources? (I'd like to add
> general support for Ruby to my distribution, creating a ruby- 
> requires and
> ruby-provides generator would be a good thing.)

For interpreter specific generators, the code is in lib/rpmfc.c (fc ==  
File Classify)
The detection & dispatching are the hard part for rpm, the gozzintas
and comesouttas and execs for helpers are fairly generic.

Currently the dispatch is mostly through libmagic, but there's various
stoopid *.foo suffix dispatch issues that keep getting hacked in
because of the well-known deficiencies of libmagic being able to
classify text correctly (the keyword search in libmagic is feeble
and is easily confused).

I can likely stub-in everything you need for ruby find/provides dispatch
rather quickly, it's harder to describe what to do than to do it. Just
say when ...

OTOH, I dunno ruby from cobol, so I haven't a clue what the ruby(...)
dependencies should look like. I can most certainly use some help  
how the ruby(...) namespace should be populated.

>> 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 ;-)
> I will. ;-) I have my own ideas on how a good packaging system  
> should look
> like, and before adapting RPM I was nearly getting started wrting my  
> own.
> It was when I discovered rpm5.org and thought something like "hey,  
> this has
> a lot of cool features you wanted." Long story short, it is in my own
> interest, so I'll certainly whine for more documentation and stuff  
> on a
> regular basis.

Polite whining eventually will get me off my duff ;-)

> ... snip ...

The names are gonna be the same as tag names. The filenames permitted
is essentically as large as the number of tag names, but is currently
limited to

/*@unchecked@*/ /*@observer@*/ /*@relnull@*/
static const char *_sysinfo_tags[] = {

I will be adding Triggername to the set soonishly, and using YAML
instead of the raw dependency parser syntax (mostly there already, but  
as soon as I can find the time to rewire syck into rpm.

> Speaking of which, are the files in the manual/ directory of the  
> source
> distribution up to date and complete? And what utility do I need to  
> convert
> them to a nicely formatted text file or HTML? (See, I *do* poke you!)
> Gee, I always keep bugging you... some day you'll ban me from the  
> ML. ;-)

NP. I'd *love* to see my implementations used sooner. The current
rate of rpm "feature" adoption is now 3+ years. E.g. lua just  
"ripened" sufficiently
that its time (imho) to make a serious effort to extend rpm with lua.
(OpenPKG has already paved the way wonderfully, thank you Ralf &  

73 de Jeff
Received on Wed Oct 29 02:22:08 2008
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.