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.
...
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
