[Rpm-maint] [PATCH 2/2] Add a call for changing package header information.

Aleksei Nikiforov darktemplar at altlinux.org
Thu Mar 29 12:55:00 UTC 2018


Hi

29.03.2018 15:51, Jeff Johnson пишет:
> 
> 
>> On Mar 29, 2018, at 4:46 AM, Aleksei Nikiforov <darktemplar at altlinux.org>
> 
> ...
> 
>>>>> Adding AUTOINSTALLED through a transaction like this is far more complex than necessary, particularly since rpm itself does not need nor use that tag for any purpose
>>>> I've looked at librpm API documentation a few moments ago and found rpmdbSetIteratorRewrite + rpmdbSetIteratorModified. Did you mean these interfaces or something else I missed which could be used for changing headers in rpm db?
>>> Yes, those interfaces. Note that those interfaces are traversed only in the case of a replaced file, which only rarely happens (multilib and sloppy packaging are the two common cases that come to mind).
>>
> 
> Apologies for not being precise.
> 
> Within rpm code, those interfaces are traversed only in the case of a replaced file, and
> hence might be considered "lightly tested" or buggy.
> 
>> Patch 2 is used to provide interface which can be used for implementation of utilities like 'apt-mark auto' or 'apt-mark manual'. In that case no files are changed, no packages are actually reinstalled, only 1 header tag value is changed (or added, if tag AUTOINSTALLED was missing).
>>
>>>> As for doing it within transaction, why not? As far as I can see almost every action on RPM db is done on open transaction, including rpmtsRebuildDB and rpmdbSetIteratorRewrite + rpmdbSetIteratorModified. Atomicity and consistency of transaction wouldn't hurt either.
>>> Here are the reasons not to implement as you have done:
>>> 0) rpm transactions are atomic/consistent only within very narrow meanings that have little to do with traditional meanings of ACID database transactions. E.g. The underlying Berkeley DB uses a CDB, not a transactional model. There are no logs nor rollbacks nor commit/discard events. Atomicity is only within an exclusive fcntl write lock, and consistency is only de facto, as in there is exactly one add/del operation per transaction element, with no well defined way to hide, say, an add/del operation until the rpm transaction is committed.
>>> 1) the rpmte interfaces aren't all that useful or compelling as an API. I can't think of any application that has used/needed access to rpmte transaction elements, because applications already have the headers from which the transaction was composed.
>>> 2) There isn't any known usage case within rpm for AUTOINSTALL, nor is there any means to compute the value within rpm which has no depsolver.
>>> Why should rpm start managing apt+rpm (my guess at what alt is doing) data? If apt wishes AUTOINSTALL, then apt, not rpm, should manage that data, and there are already sufficient API calls to perform that management task.
>>
>> Yes, depsolver is external, outside of librpm, but it is desired to keep all information in one database, including AUTOINSTALL tag, and this tag may be needed to be changed after package installation.
>>
>> How can it be implemented other way? If rpmdbSetIteratorRewrite + rpmdbSetIteratorModified only works when files are changed, then this wouldn't work for this use-case.
>>
> 
> Just do what markReplacedFile() does, but in apt-mark, outside of rpm code.
> 

Thanks for clarification, I'll try doing it and see if it works for me.

> 73
>>> 73 de Jeff
>>>> Best regards
>>>> Aleksei Nikifo

Best regards
Aleksei Nikiforov


More information about the Rpm-maint mailing list