RPM Community Forums

Mailing List Message of <rpm-lsb>

Re: LSB Package API

From: Jeff Johnson <n3npq@mac.com>
Date: Wed 25 Jun 2008 - 16:12:14 CEST
Message-id: <2675C7C7-3E70-4744-977C-2E9CA1D9293B@mac.com>

On Jun 24, 2008, at 1:38 PM, Denis Washington wrote:

>
>
>> Sound like a plan? My primary goals here are two-fold:
>>
>> 1) avoiding disasters if bogus headers start to be added to an rpmdb.
>>
>> 2) exposing rpmdbAdd() (and rpmdbRemove()) methods for use by
>> LSB/ISV/whatever applications that wish to register/unregister  
>> software
>> on RPM managed systems.
>
> Sounds like a good plan, yeah. I'm glad being able to work with you on
> this, as you certainly have a LOT more experience than me concerning
> this. Thank you very much!
>

No problem.

Enumerating the necessary data elements that need to be present
in a RPM header, and choosing _SOME_ representational markup,
would seem to be on the critical path.

(aside) dpkg its really the same fundamental problem, but a different
target metadata representation. Ditto _your_package_manager_here
for all instances of class.

There are several existing representations of "package" manifests,
both explicit and/or implicit that can be used to enumerate the
necessary data elements to be included in the target metadata  
representation
(note I did not say "rpmdb").

Simplest by far is find(1) output of a tree. i.e. an explicit list
of paths to files, with stat(2) and digest (and acls/xattrs and selinux
file contexts and whatever else is needed) implicitly derived from  
the tree.

Other soft "branding" identification information, like vendor,  
packager, description,
build host, etc would need to be added to the list of paths. While  
all of that
information may be vitally important to ISV's and LSB and installer  
GUI's,
all that rpmlib needs is NEVRA (N==name, E==epoch, etc), and mostly for
human identification rather than installer functioning purposes.

Is a find(1) path list "gud enuf" as a starting point? Or do you want  
to establish
other, alternative, markup for expressing the necessary data elements.

Other obviously complete and unsurprising candidates to describe  
necessary
data elements to be included in target metadata are "tar tvf" and/or  
"ls -al".
Those formats are explicit, no data is implicitly derived from stat 
(2) of a file,
and the file does not have to exist in order to construct a  
representation
of target metadata.

But there's lots and lots of other markups that could/should be used  
instead.

What representation of target metadata works for you?

73 de Jeff
Received on Wed Jun 25 16:12:38 2008
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.