[Rpm-devel] Should rpm create a directory of installed package
n3npq.jbj at gmail.com
Thu Jun 22 10:36:44 EDT 2006
On Jun 22, 2006, at 10:22 AM, Peter Bowen wrote:
> On Thu, 2006-06-22 at 10:05 -0400, Jeff Johnson wrote:
>> I'm in the process of trying to loosen the coupling between net-snmp
>> and rpmlib so that rpm upgrades don't force net-snmp rebuilds.
>> There's a couple of ways to achieve that uncoupling, but the easiest
>> way I can think of is to mimic other installers, and create a file in
>> a directory using name-version-release.arch as a default (but
>> changeable through configuration for those who must) template, and
>> setting the file mtime from the package installtime.
>> Opinions? Speak now, as this facility is very likely to end up in
>> rpm-4.4.7 soonishly.
> I tend to think it is a bad idea. This seems like trying to fix the
> wrong problem. The problem is really that the ond isk database format
> is rather undocumented and unstable and that there is not a stable
> API &
> ABI for accessing the database. I would suggest fixing this, rather
> than adding a new database/cache for programs to use.
Define "stable". If you mean that NPTL and concurrent access through
Berkeley DB was a huge PITA,
then we absolutely agree.
Meanwhile, database schemas don't come any simpler than inverted
lists with 2ndary lookup, and the rpmdb schema has hardly
changed for years.
What is complex is that 2ndary lookup on headers is always needed,
but that has nothing whatsoever to do
with Berkeley DB.
And if "stable" is your criteria, I ask
Why do you want a net-snmp daemon linking a known "unstable"
And, to stay on topic, ls -alt is about as stable an API as imaginable.
I have no idea why you think that 0 length files in a directory are a
> Realistically, rpm will end up dumping most of the database into the
> files in the directory, as other tools will follow net-snmp, and use
> this data. They will want to know more than use NVRA and install
> For a start epoch, but the list will just continue.
If you want a dump, then use --xml/--yaml. I see no reason atm to
populate (and maintain)
And Epoch: will never be displayed by rpm itself in default
configuration by design. You can, of course, do whatever you wish.
> If rpm wants to go down the path of database being files in a
> then the best solution is to design it now. Figure out what is
> the best way to handle it, and build rpm 5.
Please re-read the original message, 0 length files in a directory
are hardly a plan for a new database.
But I get hit repeatedly with sneers that apt is superior to rpm
because it uses flat files.
I have no problem whatsoever with adding flat file functionality to
rpm to avoid that
pointless and endless discussion with apt bigots from the Debian
Borg. Meanwhile, databases
used correctly are invariably faster than flat file access.
73 de Jeff
> Rpm-devel mailing list
> Rpm-devel at lists.dulug.duke.edu
More information about the Rpm-devel