> On Apr 10, 2018, at 10:11 AM, Aleksei Nikiforov <darktemp...@altlinux.org> 
> wrote:
> 
> Hi
> 
> 06.04.2018 18:06, Jeff Johnson пишет:
>>> On Apr 6, 2018, at 8:49 AM, Aleksei Nikiforov <darktemp...@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.
> 

Alternative interfaces to add a header to a transaction will still be subject 
to a callback.

And so we come full circle, saving AUTOINSTALL in a rpmte for a delayed/lazy 
adding of a specific tag after the callback reloads the header.

The amount of logic to save the original header, re-read a new header, and then 
replace the new header with the old (thereby positioning a file handle at the 
payload) is far more general.

Add a disabler/enabler to transaction flags for the mechanism.

73 de Jeff
>> ...
>>> 
>>> Best regards
>>> Aleksei Nikiforov
> 
> Best regards
> Aleksei Nikiforov
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Reply via email to