[Rpm-maint] [PATCH 1/2] Allow adding tag RPMTAG_AUTOINSTALLED to headers of package being installed

Aleksei Nikiforov darktemplar at altlinux.org
Tue Apr 10 14:11:07 UTC 2018


Hi

06.04.2018 18:06, Jeff Johnson пишет:
> 
> 
>> On Apr 6, 2018, at 8:49 AM, Aleksei Nikiforov <darktemplar at altlinux.org> wrote:
>>
>> Hi
>>
>> 06.04.2018 15:39, Jeff Johnson пишет:
> 
> ...
> 
>>>>
>>> Hack? I am not suggesting patching lib/rpminstall.c to add AUTOINSTALL.
>>> I am suggesting that you write a custom callback that adds AUTOINSTALL when a specific event is received, and pointed you at the CLI example. There is another example in rpm-python methods.
>>> The advantage to the notify callback is that all known rpm depsolvers already are using the callback.
>>
>> Yes, I understood that it's proposed to not patch rpm library but use existing interfaces in such unexpected way instead. I just agree that proposed approach is obscure. I'd prefer to have more clean and straightforward API for this task.
>>>>
> 
> Well the real hack is more historical than anything else and likely no longer matters.
> 
> The original "RedHat Package Manager" (circa 1998) was designed as an installer interface.
> 
> In order to run on 16Mb (that is megabyte, yes) i386 platforms, the installer used stripped (of all the bloated file information) headers in order to do dependency checking and ordering when all the headers needed to be memory resident.
> 
> All of the complex operations involved in upgrading through a transaction were unnecessary: only install was supported.
> 
> The full package header (and payload) was needed to actually perform an install. The original reason for the callback was to load the full header from the CD-ROM one-by-one as needed.
> 
> These days (heh: 20y later) all known users of rpmlib are just using full (not stripped) headers and so there is not much reason other than ancient legacy API compatibility that the original headers passed through dependency checking/ordering could not be kept (one would need to worry about fdno limits and/or re-positioning to the package payload, but that is rather straight-forward coding compared to what is actually implemented in rpm still).
> 
> If the headers were kept, then the most simple/obvious interface would be to add AUTOINSTALL (or other tags) before adding to a transaction.
> 
> There is likely a subtle way to support both modes of operation, keeping the original header or reloading the header from the original file name, by looking at some flag and not reloading the header. The file position of the payload is easily computed when needed, and the reopened file could be repositioned using seek.
> 
> So that is where the "real" hack is in rpm preventing simply adding an AUTOINSTALL tag ;-)
> 

I think I understand now why it works this way, but I still don't like 
proposed solution of modifying header data from that callback. And I 
don't think I should undertake a big task of reworking internal RPM 
logic to get rid of this old logic.

But I can make a change I mentioned earlier to allow adding any headers 
to be saved in rpmdb on package install or reinstall by providing 
interfaces similar to existing functions rpmtsAddInstallElement and 
rpmtsAddReinstallElement. I mean I'd add new functions similar to 
existing ones, not modify them. The only remaining question before I 
start implementing such change is whether such API change could be 
merged or not.

> ...
> 
>>
>> Best regards
>> Aleksei Nikiforov

Best regards
Aleksei Nikiforov


More information about the Rpm-maint mailing list