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

[Jeff Johnson]

> On Apr 6, 2018, at 8:49 AM, Aleksei Nikiforov  
> 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 ;-)

...

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

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

[Aleksei Nikiforov]

Hi

06.04.2018 15:39, Jeff Johnson пишет:




On Apr 6, 2018, at 8:14 AM, Aleksei Nikiforov  wrote:

Hi

06.04.2018 14:54, Jeff Johnson пишет:

Sent from my iPad

On Apr 6, 2018, at 3:39 AM, Aleksei Nikiforov  wrote:

Hi

05.04.2018 23:17, Jeff Johnson пишет:

Sent from my iPad

On Apr 4, 2018, at 9:25 AM, Aleksei Nikiforov  wrote:

Hi

Since patch 2 is no longer needed, could you please provide a feedback about 
patch 1? It'd be great if this patch could be merged.

I can try ...
The patch seems (from examining the patch only with limited context) to be 
propagating AUTOINSTALL from the old -> new header at the rpmte layer in order 
to ensure that the appended AUTOINSTALL tag value is persistent across package 
upgrades.
As before,  managing AUTOINSTALL persistence for a depsolver in rpmlib like 
this is rather awkward. E.g. what code should provide the add/modify/delete 
operations for AUTOINSTALL, particularly if/when the value is wrong?
I suspect (from memory, I've not checked) that there are some odd corner cases, 
particularly if/when a package is reinstalled. But perhaps dropping AUTOINSTALL 
is a feature, not a bug, in that case.
You likely should force a default value for AUTOINSTALL if/when the tag is not 
present because that is 1 fewer error returns to worry about. See how EPOCHNUM 
is implemented, likely as another header extension. You likely can use 
AUTOINSTALL as both an extension (mostly used by headerFormat) and as a 
tag-in-a-header (used by headerGet et al at the lower level) if you are careful.


No, this patch is needed for adding this tag AUTOINSTALLED on package 
installation. When package is added to transaction via functions 
rpmtsAddInstallElement or rpmtsAddReinstallElement, it takes headers as one of 
arguments. But it doesn't save header itself, it saves just enough info to find 
package's file to read header from it later, when transaction would be running. 
Header passed to function is not saved, i.e. added/modified tags are not saved. 
Since rpm file doesn't contain AUTOINSTALLED tag, and shouldn't contain it due 
to the dynamic nature of it's value, the AUTOINSTALLED tag has to be saved 
there as well, so the value can be restored later.

Ah, my bad: apologies for misanalyzing your patch (I'm on an iPad without grep, 
sigh).

So, this change only saves AUTOINSTALLED tag passed via functions 
rpmtsAddInstallElement and rpmtsAddReinstallElement. It's up to caller of those 
functions to add these headers, but if this tag isn't added function 
headerGetNumber returns 0 (i.e. sane default value). And later, when 
transaction is running, the value of this tag is restored from saved location 
and added to header read from file.

Since on package upgrade or reinstall the header is read from file again, it 
doesn't contain tag AUTOINSTALLED, and adding this tag should be safe.

Managing the value of this tag AUTOINSTALLED on package installation, reinstallation, upgrade or 
any other scenario is left to the user of library, except for setting to default value 
"zero" (meaning "manually installed") if no other value was provided.


Generally, I'd like to see RPM permit rpmlib users (like depsolvers) be able to 
freely append tags (arbitrary tagno, type, or reserved value) as needed without 
patching rpm itself.


Well, yes, it's due to lack of a method to freely add tags to installed 
packages' headers or to mark additionally added headers to be copied from 
passed header to header saved into rpmdb (that's currently 2 different headers, 
even if they're similar) that I had to make this change.

Well there is a set of methods that can be used to add AUTOINSTALL, just 
abstract and obscure.
The RPMCALLBACK_* notify callback used to push progress bars can likely be 
extended to add AUTOINSTALL (or any other tag) before the header is saved in an 
rpmdb.
Use rpmteHeader() to get the header within the callback, and pass the 
AUTOINSTALL (or any other tags to be added) state into the callback.
See rpmShowProgress() in lib/rpminstall.c for what the rpm CLI does.


Well, that looks like a hack I wouldn't want to implement.



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.



If generic solution is desired for current change, it might be a good idea to 
modify functions rpmtsAddInstallElement and rpmtsAddReinstallElement and add 
new argument to these 

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

[Jeff Johnson]

> On Apr 6, 2018, at 8:14 AM, Aleksei Nikiforov  
> wrote:
> 
> Hi
> 
> 06.04.2018 14:54, Jeff Johnson пишет:
>> Sent from my iPad
>>> On Apr 6, 2018, at 3:39 AM, Aleksei Nikiforov  
>>> wrote:
>>> 
>>> Hi
>>> 
>>> 05.04.2018 23:17, Jeff Johnson пишет:
 Sent from my iPad
> On Apr 4, 2018, at 9:25 AM, Aleksei Nikiforov  
> wrote:
> 
> Hi
> 
> Since patch 2 is no longer needed, could you please provide a feedback 
> about patch 1? It'd be great if this patch could be merged.
 I can try ...
 The patch seems (from examining the patch only with limited context) to be 
 propagating AUTOINSTALL from the old -> new header at the rpmte layer in 
 order to ensure that the appended AUTOINSTALL tag value is persistent 
 across package upgrades.
 As before,  managing AUTOINSTALL persistence for a depsolver in rpmlib 
 like this is rather awkward. E.g. what code should provide the 
 add/modify/delete operations for AUTOINSTALL, particularly if/when the 
 value is wrong?
 I suspect (from memory, I've not checked) that there are some odd corner 
 cases, particularly if/when a package is reinstalled. But perhaps dropping 
 AUTOINSTALL is a feature, not a bug, in that case.
 You likely should force a default value for AUTOINSTALL if/when the tag is 
 not present because that is 1 fewer error returns to worry about. See how 
 EPOCHNUM is implemented, likely as another header extension. You likely 
 can use AUTOINSTALL as both an extension (mostly used by headerFormat) and 
 as a tag-in-a-header (used by headerGet et al at the lower level) if you 
 are careful.
>>> 
>>> No, this patch is needed for adding this tag AUTOINSTALLED on package 
>>> installation. When package is added to transaction via functions 
>>> rpmtsAddInstallElement or rpmtsAddReinstallElement, it takes headers as one 
>>> of arguments. But it doesn't save header itself, it saves just enough info 
>>> to find package's file to read header from it later, when transaction would 
>>> be running. Header passed to function is not saved, i.e. added/modified 
>>> tags are not saved. Since rpm file doesn't contain AUTOINSTALLED tag, and 
>>> shouldn't contain it due to the dynamic nature of it's value, the 
>>> AUTOINSTALLED tag has to be saved there as well, so the value can be 
>>> restored later.
>> Ah, my bad: apologies for misanalyzing your patch (I'm on an iPad without 
>> grep, sigh).
>>> So, this change only saves AUTOINSTALLED tag passed via functions 
>>> rpmtsAddInstallElement and rpmtsAddReinstallElement. It's up to caller of 
>>> those functions to add these headers, but if this tag isn't added function 
>>> headerGetNumber returns 0 (i.e. sane default value). And later, when 
>>> transaction is running, the value of this tag is restored from saved 
>>> location and added to header read from file.
>>> 
>>> Since on package upgrade or reinstall the header is read from file again, 
>>> it doesn't contain tag AUTOINSTALLED, and adding this tag should be safe.
>>> 
>>> Managing the value of this tag AUTOINSTALLED on package installation, 
>>> reinstallation, upgrade or any other scenario is left to the user of 
>>> library, except for setting to default value "zero" (meaning "manually 
>>> installed") if no other value was provided.
>>> 
 Generally, I'd like to see RPM permit rpmlib users (like depsolvers) be 
 able to freely append tags (arbitrary tagno, type, or reserved value) as 
 needed without patching rpm itself.
>>> 
>>> Well, yes, it's due to lack of a method to freely add tags to installed 
>>> packages' headers or to mark additionally added headers to be copied from 
>>> passed header to header saved into rpmdb (that's currently 2 different 
>>> headers, even if they're similar) that I had to make this change.
>> Well there is a set of methods that can be used to add AUTOINSTALL, just 
>> abstract and obscure.
>> The RPMCALLBACK_* notify callback used to push progress bars can likely be 
>> extended to add AUTOINSTALL (or any other tag) before the header is saved in 
>> an rpmdb.
>> Use rpmteHeader() to get the header within the callback, and pass the 
>> AUTOINSTALL (or any other tags to be added) state into the callback.
>> See rpmShowProgress() in lib/rpminstall.c for what the rpm CLI does.
> 
> Well, that looks like a hack I wouldn't want to implement.
> 

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.

> If generic solution is desired for current change, it might be a good idea to 
> modify functions rpmtsAddInstallElement and 

Re: [Rpm-maint] [PATCH] Add RPMTAG_IDENTITY calculation as tag extension

[Jeff Johnson]

Sent from my iPad

> On Apr 6, 2018, at 1:52 AM, Panu Matilainen  wrote:
> 
>> On 04/05/2018 03:42 PM, Vladimir D. Seleznev wrote:
>>> On Thu, Apr 05, 2018 at 11:41:33AM +0300, Panu Matilainen wrote:
 On 04/03/2018 10:31 PM, Vladimir D. Seleznev wrote:
 RPMTAG_IDENTITY is calculating as digest of part of package header that
 does not contain irrelevant to package build tag entries.
 
 Mathematically RPMTAG_IDENTITY value is a result of function of two
 variable: a package header and an rpm utility, thus this value can
 differ for same package and different version of rpm.
>>> 
>>> Before proceeding with further work on this, we need to define what is
>>> it that we're trying to identify. The above definition is very
>>> ambiguous, and it's impossible to properly review + discuss the patch
>>> when my idea of package identity might be entirely different from
>>> somebody elses idea, that'll only cause unnecessary work and frustration.
>> Agree, that commit message isn't clear.
>>> Starting with, what is a "package"? Are we talking about the source
>>> package, or binary packages?
>> Originally it was about binary packages, but is there really difference?
>> Source packages are building as well as binary, and something can be
>> changed after rebuild.
> 
> Source *packages* are built too, yes, but there's a vast difference between 
> reproducability of src.rpm and binary rpm.
> 
> However while reviewing the patch yesterday, I realized I've been 
> increasingly thinking about *source* identity (note the lack of "package"), 
> which is something quite different: you'd calculate a digest over the 
> unparsed spec + all the sources and patches etc the spec refers to [*] and 
> save it in the header of binaries and sources on build. This would let you 
> identify all the packages that have been built from the same source, ie 
> whether the package was built eg on Fedora or RHEL (it's fairly common to 
> share specs between them) or whatever it'd have the same source id.
> 
> [*] obviously you need to parse the spec to get those references and it's 
> possible to create specs where this differs between arches, but sane specs 
> use same sources + patches between archs etc
> 
>>> If it's binaries, then we're always ultimately talking about a *build*,
>>> and a line needs to be drawn somewhere.
>> OK.
>>> There are any number of ways to draw such a line, so it needs to be
>>> explicitly stated. One example of such line could be something like
>>> "package id must match between a package built on different instances
>>> of the same operating system, version and architecture". That clearly
>>> is NOT the line that this version of the patch tries to draw, but then
>>> it's not at all clear to me what that line is supposed to be.
>> I think, there should be a line with other side idea: if package
>> identity is matched between package build on the same build environment,
>> then the build is reproducible.
>> The possible new version of commit massage is below:
>> Add RPMTAG_IDENTITY calculation as tag extension
>> RPMTAG_IDENTITY is calculating as digest of values of significant
>> package header tag entries and represents package build characteristics.
>> The main purpose of package identity is reproducible build verification:
>> if package identity is matched between package build on same build
>> environment, then the package build is reproducible for this
>> environment.
> 
> Right, reproducability is one such line and that'd be a much better 
> description.
> 
> I do think that RPMTAG_IDENTITY is overly broad name for such a narrow 
> purpose though - note how it led me to think about the source level identity 
> instead. Something towards "build id" maybe, but we don't want to mix it up 
> with debuginfo buildid. No need to get hung over it right now though, just 
> something to think about.
> 

To handle multiple types of reproducibility, IDENTITY needs to be computed 
across an array of hashes of elements, not the elements themselves.

One reason for the added abstraction layer in an array of hashes of elements is 
to diagnose proof-of-reproducibility failures: when IDENTITY fails, one can 
then identify which element failed.

For the (overly simple) case of tags in a header, the array of hashes is of 
each tag's data, and IDENTITY is then the digest of the array. For diagnostic 
purposes, the tag name should also be appended to the tag data hash.

By using a hash on an array of hashes, the mechanism can be chained/extended.

Consider, say, a TRANSACTION_IDENTITY composed as an array of package IDENTITY 
hashes composed of tag data elements in the (overly simple) example we have 
been considering.

See what NixOS (a package manager based on functional programming concepts) 
does to append human readable strings to hashes for an easily readable format 
for the array elements in the IDENTITY value.

hth

73 de Jeff
>- Panu -
> 

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

[Aleksei Nikiforov]

Hi

06.04.2018 14:54, Jeff Johnson пишет:



Sent from my iPad


On Apr 6, 2018, at 3:39 AM, Aleksei Nikiforov  wrote:

Hi

05.04.2018 23:17, Jeff Johnson пишет:

Sent from my iPad

On Apr 4, 2018, at 9:25 AM, Aleksei Nikiforov  wrote:

Hi

Since patch 2 is no longer needed, could you please provide a feedback about 
patch 1? It'd be great if this patch could be merged.


I can try ...
The patch seems (from examining the patch only with limited context) to be 
propagating AUTOINSTALL from the old -> new header at the rpmte layer in order 
to ensure that the appended AUTOINSTALL tag value is persistent across package 
upgrades.
As before,  managing AUTOINSTALL persistence for a depsolver in rpmlib like 
this is rather awkward. E.g. what code should provide the add/modify/delete 
operations for AUTOINSTALL, particularly if/when the value is wrong?
I suspect (from memory, I've not checked) that there are some odd corner cases, 
particularly if/when a package is reinstalled. But perhaps dropping AUTOINSTALL 
is a feature, not a bug, in that case.
You likely should force a default value for AUTOINSTALL if/when the tag is not 
present because that is 1 fewer error returns to worry about. See how EPOCHNUM 
is implemented, likely as another header extension. You likely can use 
AUTOINSTALL as both an extension (mostly used by headerFormat) and as a 
tag-in-a-header (used by headerGet et al at the lower level) if you are careful.


No, this patch is needed for adding this tag AUTOINSTALLED on package 
installation. When package is added to transaction via functions 
rpmtsAddInstallElement or rpmtsAddReinstallElement, it takes headers as one of 
arguments. But it doesn't save header itself, it saves just enough info to find 
package's file to read header from it later, when transaction would be running. 
Header passed to function is not saved, i.e. added/modified tags are not saved. 
Since rpm file doesn't contain AUTOINSTALLED tag, and shouldn't contain it due 
to the dynamic nature of it's value, the AUTOINSTALLED tag has to be saved 
there as well, so the value can be restored later.



Ah, my bad: apologies for misanalyzing your patch (I'm on an iPad without grep, 
sigh).


So, this change only saves AUTOINSTALLED tag passed via functions 
rpmtsAddInstallElement and rpmtsAddReinstallElement. It's up to caller of those 
functions to add these headers, but if this tag isn't added function 
headerGetNumber returns 0 (i.e. sane default value). And later, when 
transaction is running, the value of this tag is restored from saved location 
and added to header read from file.

Since on package upgrade or reinstall the header is read from file again, it 
doesn't contain tag AUTOINSTALLED, and adding this tag should be safe.

Managing the value of this tag AUTOINSTALLED on package installation, reinstallation, upgrade or 
any other scenario is left to the user of library, except for setting to default value 
"zero" (meaning "manually installed") if no other value was provided.


Generally, I'd like to see RPM permit rpmlib users (like depsolvers) be able to 
freely append tags (arbitrary tagno, type, or reserved value) as needed without 
patching rpm itself.


Well, yes, it's due to lack of a method to freely add tags to installed 
packages' headers or to mark additionally added headers to be copied from 
passed header to header saved into rpmdb (that's currently 2 different headers, 
even if they're similar) that I had to make this change.



Well there is a set of methods that can be used to add AUTOINSTALL, just 
abstract and obscure.

The RPMCALLBACK_* notify callback used to push progress bars can likely be 
extended to add AUTOINSTALL (or any other tag) before the header is saved in an 
rpmdb.

Use rpmteHeader() to get the header within the callback, and pass the 
AUTOINSTALL (or any other tags to be added) state into the callback.

See rpmShowProgress() in lib/rpminstall.c for what the rpm CLI does.



Well, that looks like a hack I wouldn't want to implement.

If generic solution is desired for current change, it might be a good 
idea to modify functions rpmtsAddInstallElement and 
rpmtsAddReinstallElement and add new argument to these functions. Or add 
new versions of these functions and keep current ones for backwards 
compatibility. This argument would be some sort of container of tags and 
their values which would be added to header saved to rpmdb.



hth

73 de Jeff


Yes, the header unload needs to be fixed to support more than just an int8 data 
type for full generality.
hth
73 de Jeff

28.03.2018 14:58, Aleksei Nikiforov пишет:

Signed-off-by: Aleksei Nikiforov 
---
  lib/rpmte.c | 8 
  1 file changed, 8 insertions(+)
diff --git a/lib/rpmte.c b/lib/rpmte.c
index 40aa5e9..238c8b6 100644
--- a/lib/rpmte.c
+++ b/lib/rpmte.c
@@ -39,6 +39,7 @@ struct rpmte_s {
  char * arch;/*!< Architecture hint. */
  char 

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

[Jeff Johnson]

Sent from my iPad

> On Apr 6, 2018, at 3:39 AM, Aleksei Nikiforov  
> wrote:
> 
> Hi
> 
> 05.04.2018 23:17, Jeff Johnson пишет:
>> Sent from my iPad
>>> On Apr 4, 2018, at 9:25 AM, Aleksei Nikiforov  
>>> wrote:
>>> 
>>> Hi
>>> 
>>> Since patch 2 is no longer needed, could you please provide a feedback 
>>> about patch 1? It'd be great if this patch could be merged.
>>> 
>> I can try ...
>> The patch seems (from examining the patch only with limited context) to be 
>> propagating AUTOINSTALL from the old -> new header at the rpmte layer in 
>> order to ensure that the appended AUTOINSTALL tag value is persistent across 
>> package upgrades.
>> As before,  managing AUTOINSTALL persistence for a depsolver in rpmlib like 
>> this is rather awkward. E.g. what code should provide the add/modify/delete 
>> operations for AUTOINSTALL, particularly if/when the value is wrong?
>> I suspect (from memory, I've not checked) that there are some odd corner 
>> cases, particularly if/when a package is reinstalled. But perhaps dropping 
>> AUTOINSTALL is a feature, not a bug, in that case.
>> You likely should force a default value for AUTOINSTALL if/when the tag is 
>> not present because that is 1 fewer error returns to worry about. See how 
>> EPOCHNUM is implemented, likely as another header extension. You likely can 
>> use AUTOINSTALL as both an extension (mostly used by headerFormat) and as a 
>> tag-in-a-header (used by headerGet et al at the lower level) if you are 
>> careful.
> 
> No, this patch is needed for adding this tag AUTOINSTALLED on package 
> installation. When package is added to transaction via functions 
> rpmtsAddInstallElement or rpmtsAddReinstallElement, it takes headers as one 
> of arguments. But it doesn't save header itself, it saves just enough info to 
> find package's file to read header from it later, when transaction would be 
> running. Header passed to function is not saved, i.e. added/modified tags are 
> not saved. Since rpm file doesn't contain AUTOINSTALLED tag, and shouldn't 
> contain it due to the dynamic nature of it's value, the AUTOINSTALLED tag has 
> to be saved there as well, so the value can be restored later.
> 

Ah, my bad: apologies for misanalyzing your patch (I'm on an iPad without grep, 
sigh).

> So, this change only saves AUTOINSTALLED tag passed via functions 
> rpmtsAddInstallElement and rpmtsAddReinstallElement. It's up to caller of 
> those functions to add these headers, but if this tag isn't added function 
> headerGetNumber returns 0 (i.e. sane default value). And later, when 
> transaction is running, the value of this tag is restored from saved location 
> and added to header read from file.
> 
> Since on package upgrade or reinstall the header is read from file again, it 
> doesn't contain tag AUTOINSTALLED, and adding this tag should be safe.
> 
> Managing the value of this tag AUTOINSTALLED on package installation, 
> reinstallation, upgrade or any other scenario is left to the user of library, 
> except for setting to default value "zero" (meaning "manually installed") if 
> no other value was provided.
> 
>> Generally, I'd like to see RPM permit rpmlib users (like depsolvers) be able 
>> to freely append tags (arbitrary tagno, type, or reserved value) as needed 
>> without patching rpm itself.
> 
> Well, yes, it's due to lack of a method to freely add tags to installed 
> packages' headers or to mark additionally added headers to be copied from 
> passed header to header saved into rpmdb (that's currently 2 different 
> headers, even if they're similar) that I had to make this change.
> 

Well there is a set of methods that can be used to add AUTOINSTALL, just 
abstract and obscure.

The RPMCALLBACK_* notify callback used to push progress bars can likely be 
extended to add AUTOINSTALL (or any other tag) before the header is saved in an 
rpmdb.

Use rpmteHeader() to get the header within the callback, and pass the 
AUTOINSTALL (or any other tags to be added) state into the callback.

See rpmShowProgress() in lib/rpminstall.c for what the rpm CLI does.

hth

73 de Jeff

>> Yes, the header unload needs to be fixed to support more than just an int8 
>> data type for full generality.
>> hth
>> 73 de Jeff
>>> 28.03.2018 14:58, Aleksei Nikiforov пишет:
 Signed-off-by: Aleksei Nikiforov 
 ---
  lib/rpmte.c | 8 
  1 file changed, 8 insertions(+)
 diff --git a/lib/rpmte.c b/lib/rpmte.c
 index 40aa5e9..238c8b6 100644
 --- a/lib/rpmte.c
 +++ b/lib/rpmte.c
 @@ -39,6 +39,7 @@ struct rpmte_s {
  char * arch;/*!< Architecture hint. */
  char * os;/*!< Operating system hint. */
  int isSource;/*!< (TR_ADDED) source rpm? */
 +uint32_t autoinstalled;/*! Indicates whether package was 
 installed just as dependency satisfier or not */
rpmte depends;  /*!< 

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

[Aleksei Nikiforov]

Hi

05.04.2018 23:17, Jeff Johnson пишет:



Sent from my iPad


On Apr 4, 2018, at 9:25 AM, Aleksei Nikiforov  wrote:

Hi

Since patch 2 is no longer needed, could you please provide a feedback about 
patch 1? It'd be great if this patch could be merged.



I can try ...

The patch seems (from examining the patch only with limited context) to be 
propagating AUTOINSTALL from the old -> new header at the rpmte layer in order 
to ensure that the appended AUTOINSTALL tag value is persistent across package 
upgrades.

As before,  managing AUTOINSTALL persistence for a depsolver in rpmlib like 
this is rather awkward. E.g. what code should provide the add/modify/delete 
operations for AUTOINSTALL, particularly if/when the value is wrong?

I suspect (from memory, I've not checked) that there are some odd corner cases, 
particularly if/when a package is reinstalled. But perhaps dropping AUTOINSTALL 
is a feature, not a bug, in that case.

You likely should force a default value for AUTOINSTALL if/when the tag is not 
present because that is 1 fewer error returns to worry about. See how EPOCHNUM 
is implemented, likely as another header extension. You likely can use 
AUTOINSTALL as both an extension (mostly used by headerFormat) and as a 
tag-in-a-header (used by headerGet et al at the lower level) if you are careful.



No, this patch is needed for adding this tag AUTOINSTALLED on package 
installation. When package is added to transaction via functions 
rpmtsAddInstallElement or rpmtsAddReinstallElement, it takes headers as 
one of arguments. But it doesn't save header itself, it saves just 
enough info to find package's file to read header from it later, when 
transaction would be running. Header passed to function is not saved, 
i.e. added/modified tags are not saved. Since rpm file doesn't contain 
AUTOINSTALLED tag, and shouldn't contain it due to the dynamic nature of 
it's value, the AUTOINSTALLED tag has to be saved there as well, so the 
value can be restored later.


So, this change only saves AUTOINSTALLED tag passed via functions 
rpmtsAddInstallElement and rpmtsAddReinstallElement. It's up to caller 
of those functions to add these headers, but if this tag isn't added 
function headerGetNumber returns 0 (i.e. sane default value). And later, 
when transaction is running, the value of this tag is restored from 
saved location and added to header read from file.


Since on package upgrade or reinstall the header is read from file 
again, it doesn't contain tag AUTOINSTALLED, and adding this tag should 
be safe.


Managing the value of this tag AUTOINSTALLED on package installation, 
reinstallation, upgrade or any other scenario is left to the user of 
library, except for setting to default value "zero" (meaning "manually 
installed") if no other value was provided.



Generally, I'd like to see RPM permit rpmlib users (like depsolvers) be able to 
freely append tags (arbitrary tagno, type, or reserved value) as needed without 
patching rpm itself.



Well, yes, it's due to lack of a method to freely add tags to installed 
packages' headers or to mark additionally added headers to be copied 
from passed header to header saved into rpmdb (that's currently 2 
different headers, even if they're similar) that I had to make this change.



Yes, the header unload needs to be fixed to support more than just an int8 data 
type for full generality.

hth

73 de Jeff

28.03.2018 14:58, Aleksei Nikiforov пишет:

Signed-off-by: Aleksei Nikiforov 
---
  lib/rpmte.c | 8 
  1 file changed, 8 insertions(+)
diff --git a/lib/rpmte.c b/lib/rpmte.c
index 40aa5e9..238c8b6 100644
--- a/lib/rpmte.c
+++ b/lib/rpmte.c
@@ -39,6 +39,7 @@ struct rpmte_s {
  char * arch;/*!< Architecture hint. */
  char * os;/*!< Operating system hint. */
  int isSource;/*!< (TR_ADDED) source rpm? */
+uint32_t autoinstalled;/*! Indicates whether package was installed 
just as dependency satisfier or not */
rpmte depends;  /*!< Package updated by this package (ERASE 
te) */
  rpmte parent;/*!< Parent transaction element. */
@@ -191,6 +192,8 @@ static int addTE(rpmte p, Header h, fnpyKey key, 
rpmRelocation * relocs)
  if (p->type == TR_ADDED)
  p->pkgFileSize = headerGetNumber(h, RPMTAG_LONGSIGSIZE) + 96 + 256;
  +p->autoinstalled = headerGetNumber(h, RPMTAG_AUTOINSTALLED);
+
  rc = 0;
exit:
@@ -576,6 +579,11 @@ static int rpmteOpen(rpmte te, int reload_fi)
  rc = 1;
  }
  
+if (rc)

+{
+rc = (headerPutUint32(h, RPMTAG_AUTOINSTALLED, &(te->autoinstalled), 
1) == 1);
+}
+
  rpmteSetHeader(te, h);
  headerFree(h);
  }


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