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

[Aleksei Nikiforov]

This is needed to allow changing autoinstalled header tag without actually 
reinstalling package from file.
This may be useful in case you need to modify autoinstalled flag of package 
which is updated in repository or removed from it
without actually updating or otherwise changing package.

Signed-off-by: Aleksei Nikiforov 
---
 lib/depends.c| 26 --
 lib/order.c  | 23 ---
 lib/psm.c| 40 +++-
 lib/rpmte.c  | 11 +++
 lib/rpmte.h  |  1 +
 lib/rpmte_internal.h |  3 ++-
 lib/rpmts.c  |  1 +
 lib/rpmts.h  | 15 ++-
 lib/transaction.c| 18 ++
 plugins/syslog.c | 18 +-
 python/rpmmodule.c   |  1 +
 11 files changed, 132 insertions(+), 25 deletions(-)

diff --git a/lib/depends.c b/lib/depends.c
index 9f4db8f..2f95657 100644
--- a/lib/depends.c
+++ b/lib/depends.c
@@ -70,6 +70,7 @@ enum addOp_e {
 RPMTE_INSTALL  = 0,
 RPMTE_UPGRADE  = 1,
 RPMTE_REINSTALL= 2,
+RPMTE_CHANGE   = 3,
 };
 
 /**
@@ -422,13 +423,13 @@ static int addPackage(rpmts ts, Header h,
 int oc = tsmem->orderCount;
 
 /* Check for supported payload format if it's a package */
-if (key && headerCheckPayloadFormat(h) != RPMRC_OK) {
+if ((op != RPMTE_CHANGE) && key && headerCheckPayloadFormat(h) != 
RPMRC_OK) {
ec = 1;
goto exit;
 }
 
 /* Source packages are never "upgraded" */
-if (isSource)
+if ((op != RPMTE_CHANGE) && isSource)
op = RPMTE_INSTALL;
 
 /* Do lazy (readonly?) open of rpm database for upgrades. */
@@ -437,14 +438,14 @@ static int addPackage(rpmts ts, Header h,
goto exit;
 }
 
-p = rpmteNew(ts, h, TR_ADDED, key, relocs);
+p = rpmteNew(ts, h, (op != RPMTE_CHANGE) ? TR_ADDED : TR_CHANGED, key, 
relocs);
 if (p == NULL) {
ec = 1;
goto exit;
 }
 
 /* Check binary packages for redundancies in the set */
-if (!isSource) {
+if ((op == RPMTE_CHANGE) || (!isSource)) {
oc = findPos(ts, tscolor, p, (op == RPMTE_UPGRADE));
/* If we're replacing a previously added element, free the old one */
if (oc >= 0 && oc < tsmem->orderCount) {
@@ -477,8 +478,11 @@ static int addPackage(rpmts ts, Header h,
 
 /* Add erasure elements for old versions and obsoletions on upgrades */
 /* XXX TODO: If either of these fails, we'd need to undo all additions */
-if (op != RPMTE_INSTALL)
-   addSelfErasures(ts, tscolor, op, p, rpmteColor(p), h);
+if ((op != RPMTE_INSTALL) && (op != RPMTE_CHANGE))
+{
+addSelfErasures(ts, tscolor, op, p, rpmteColor(p), h);
+}
+
 if (op == RPMTE_UPGRADE)
addObsoleteErasures(ts, tscolor, p);
 
@@ -504,6 +508,16 @@ int rpmtsAddReinstallElement(rpmts ts, Header h, fnpyKey 
key)
 return addPackage(ts, h, key, RPMTE_REINSTALL, NULL);
 }
 
+int rpmtsAddChangeElement(rpmts ts, Header h)
+{
+if (rpmtsSetupTransactionPlugins(ts) == RPMRC_FAIL)
+{
+return 1;
+}
+
+return addPackage(ts, h, NULL, RPMTE_CHANGE, NULL);
+}
+
 int rpmtsAddEraseElement(rpmts ts, Header h, int dboffset)
 {
 if (rpmtsSetupTransactionPlugins(ts) == RPMRC_FAIL)
diff --git a/lib/order.c b/lib/order.c
index 7a1dd10..4610794 100644
--- a/lib/order.c
+++ b/lib/order.c
@@ -633,9 +633,26 @@ int rpmtsOrder(rpmts ts)
 
 rpmlog(RPMLOG_DEBUG, "== tsorting packages (order, #predecessors, 
#succesors, depth)\n");
 
-for (int i = 0; i < 2; i++) {
-   /* Do two separate runs: installs first - then erases */
-   int oType = !i ? TR_ADDED : TR_REMOVED;
+for (int i = 0; i < 3; i++) {
+   /* Do three separate runs: installs first - then erases, and changes 
after that */
+   int oType;
+
+   switch (i)
+   {
+   case 0:
+   oType = TR_ADDED;
+   break;
+   case 1:
+   oType = TR_REMOVED;
+   break;
+   case 2:
+   oType = TR_CHANGED;
+   break;
+   default:
+   return -1;
+   break;
+   }
+
q = r = NULL;
/* Scan for zeroes and add them to the queue */
for (int e = 0; e < nelem; e++) {
diff --git a/lib/psm.c b/lib/psm.c
index f3a7ce4..c2d6be2 100644
--- a/lib/psm.c
+++ b/lib/psm.c
@@ -531,7 +531,7 @@ static void markReplacedInstance(rpmts ts, rpmte te)
 rpmdbFreeIterator(mi);
 }
 
-static rpmRC dbAdd(rpmts ts, rpmte te)
+static rpmRC dbAdd(rpmts ts, rpmte te, unsigned int oldDBInstance)
 {
 Header h = rpmteHeader(te);
 rpm_time_t installTime = (rpm_time_t) time(NULL);
@@ -542,13 +542,21 @@ static rpmRC dbAdd(rpmts ts, rpmte te)
 rpm_tid_t tid = rpmtsGetTid(ts);
 rpmRC rc;
 
-if (fileStates != NULL && fc > 0) {
-   headerPutChar(h, RPMTAG_FILESTATES, fileStates, fc);
-}
+   /*
+* if oldDBInstance is 

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

[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);
 }
-- 
2.10.4

___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] RPM 4.13.1 released!

[Panu Matilainen]

This is a bug fix and enhancement update to the stable 4.13.x branch. In 
particular, several file trigger related bugs (previously addressed in 
4.14.x) are fixed in this release. Additionally, support for 
with/without/unless rich dependencies has been backported in this release.


The reason for the "unexpected" rich dependency backport is that we 
failed to add a new rpmlib() dependency tracker when adding these new 
dependencies, and thus rpm 4.13.0* wont refuse to touch packages using 
them as it should. We cannot fix what happened after the fact, but this 
is our attempt to make up for it.


For details and download information, see

http://rpm.org/wiki/Releases/4.13.1

On behalf of the rpm-team,

- Panu -
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

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

[Jeff Johnson]

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

There are already existing rpm interfaces to retrieve a header, add a tag, and 
re-register the header.

What is the justification for doing this operation within an rpm transaction?

73 de Jeff
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

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

[Jeff Johnson]

> On Mar 28, 2018, at 11:52 AM, Aleksei Nikiforov  
> wrote:
> 
> Hi
> 
> 28.03.2018 15:21, Jeff Johnson пишет:
>> 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 whatsoever.
>> There are already existing rpm interfaces to retrieve a header, add a tag, 
>> and re-register the header.
>> What is the justification for doing this operation within an rpm transaction?
>> 73 de Jeff
>> ___
>> Rpm-maint mailing list
>> Rpm-maint@lists.rpm.org
>> http://lists.rpm.org/mailman/listinfo/rpm-maint
> 
> When I was considering possible ways of implementing this feature I found 
> only rpmtsAddInstallElement, rpmtsAddReinstallElement and rpmtsRebuildDB, and 
> none of those functions worked for this purpose quite well. So I had to 
> implement it the way it was required.
> 

The rpmtsAdd* interfaces take a header that can have AUTOINSTALL (or any other 
tag) appended as you wish.

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

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

73 de Jeff




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

Re: [Rpm-maint] [rpm-software-management/rpm] find-debuginfo.sh expects ELF-files to be executable (#422)

[Sergey Avseyev]

Closed #422.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/422#event-1546438120___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] find-debuginfo.sh expects ELF-files to be executable (#422)

[Sergey Avseyev]

OK. thanks. Not a bug then. I can fix it in the spec

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/422#issuecomment-377013398___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] find-debuginfo.sh expects ELF-files to be executable (#422)

[Mark Hatle]

My understanding is that this was done as way to allow the package maintainer 
to PREVENT debug processing.  There are numerous cases, where the debugedit 
split/strip behavior can trigger problems.  So by using the executable flag, it 
was easy to disable special processing for those items.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/422#issuecomment-376968477___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] Dual signing with rpm

[Jeff Johnson]

> On Mar 28, 2018, at 8:00 PM, Burhan Wani (burwani)  wrote:
> 
> Hello,
> I wanted to know why dual signing feature was removed from rpm 4.2 onwards. 
> Is there a security risk to using rpm dual signing ? What would be the best 
> way to implement dual signing in rpm.
>  

rpm has never supported "dual signing" if you mean signing with 2 different 
keys.
While there were ways to sign twice, with different algorithms, which ended up
in different tags, only one of those signatures was ever verified.

It doesn't make much sense to have multiple signatures, you are better off 
using a longer key or hash.

What exactly is "dual signing" to you?

73 de Jeff
>  
> Regards,
> Burhan Wani 
>  
> ___
> Rpm-maint mailing list
> Rpm-maint@lists.rpm.org
> http://lists.rpm.org/mailman/listinfo/rpm-maint
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] Dual signing with rpm

[Burhan Wani (burwani)]

Hello,
I wanted to know why dual signing feature was removed from rpm 4.2 onwards. Is 
there a security risk to using rpm dual signing ? What would be the best way to 
implement dual signing in rpm.


Regards,
Burhan Wani

___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

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

[Aleksei Nikiforov]

Hi

28.03.2018 15:21, Jeff Johnson пишет:


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

There are already existing rpm interfaces to retrieve a header, add a tag, and 
re-register the header.

What is the justification for doing this operation within an rpm transaction?

73 de Jeff
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint



When I was considering possible ways of implementing this feature I 
found only rpmtsAddInstallElement, rpmtsAddReinstallElement and 
rpmtsRebuildDB, and none of those functions worked for this purpose 
quite well. So I had to implement it the way it was required.


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?


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.


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