This patch basically adds a dependency (for ordering purposes)
as if every erased packages had a Requires: on whatever package(s)
caused the erasure.
That should ensure install-before-erase always.
The patch has been tested with a 127 pkg transaction that had
13 loops, and install-before-erase
There's one more part to this implementation, eliding
a -U into a -i if/when a -debuginfo upgrade is attempted.
But caveat emptor (and very lightly testedn so far). The goal for a
different
upgrade policy with -debugfo packages is described here
https://bugzilla.redhat.com/process_bug.cgi
On Fri, May 30, 2008 at 9:19 PM, Jeff Johnson [EMAIL PROTECTED]
wrote:
There's one more part to this implementation, eliding
a -U into a -i if/when a -debuginfo upgrade is attempted.
But caveat emptor (and very lightly testedn so far). The goal for a
different
upgrade policy with
On May 30, 2008, at 4:29 PM, devzero2000 wrote:
On Fri, May 30, 2008 at 9:19 PM, Jeff Johnson
[EMAIL PROTECTED] wrote:
There's one more part to this implementation, eliding
a -U into a -i if/when a -debuginfo upgrade is attempted.
But caveat emptor (and very lightly testedn so
This change likely needs some context ...
There's a desire to manage -debuginfo*.rpm packages through upgrades.
But an upgrade for -debuginfo packages needs (imho) a different
upgrade model.
You can see my attempt to describe what I think is needed for -debuginfo
upgrades at comment #4 here:
On Thu, Jan 31, 2008, Jeff Johnson wrote:
- jbj: fix: retrieve originTime from old, not new, header.
[...]
/* Snarf the original install time from older package(s). */
he-tag = RPMTAG_ORIGINTIME;
- xx = headerGet(h, he, 0);
+ xx = headerGet(oh, he, 0);
if (xx
On Jan 31, 2008, at 11:36 AM, Ralf S. Engelschall wrote:
Unfortunately, it think there is still a bug somewhere:
The --force may be what is confusing.
IIRC, this code in lib/psm.c fires iff --force is specfied:
/*
* If this header has already been installed, remove
On Jan 31, 2008, at 1:05 PM, Ralf S. Engelschall wrote:
On Thu, Jan 31, 2008, Ralf S. Engelschall wrote:
On Thu, Jan 31, 2008, Jeff Johnson wrote:
On Jan 31, 2008, at 11:36 AM, Ralf S. Engelschall wrote:
Unfortunately, it think there is still a bug somewhere:
The --force may be what is
On Jan 31, 2008, at 1:05 PM, Ralf S. Engelschall wrote:
But the problem has to do with rebuilding! If one rebuilds (rpm -
bb) a new
binary RPM from scratch, the upgrade works exactly one time. On all
subsequent
reinstalls (rpm -Uvh [--force]) of the same binary RPM the
ORIGINTIME
is reset
On Jan 31, 2008, at 1:22 PM, Ralf S. Engelschall wrote:
On Thu, Jan 31, 2008, Jeff Johnson wrote:
On Jan 31, 2008, at 12:55 PM, Ralf S. Engelschall wrote:
Will try. Had to use --force because the exactly same package
(NEVRA)
was already installed. If --force is the problem we have to
On Thu, Jan 31, 2008, Jeff Johnson wrote:
On Jan 31, 2008, at 1:45 PM, Ralf S. Engelschall wrote:
You mean with respect to ORIGINTIME? It shoudln't matter.
ORIGINTIME should depend just on N and not on NEVRA, i.e.,
As pointed out, RPMTAG_PROVIDENAME, not RPMTAG_NAME is used.
There's a
On Jan 31, 2008, at 2:07 PM, Ralf S. Engelschall wrote:
On Thu, Jan 31, 2008, Jeff Johnson wrote:
On Jan 31, 2008, at 1:45 PM, Ralf S. Engelschall wrote:
You mean with respect to ORIGINTIME? It shoudln't matter.
ORIGINTIME should depend just on N and not on NEVRA, i.e.,
As pointed out,
On Thu, Jan 31, 2008, Jeff Johnson wrote:
[...]
Cool. I just see one small time difference possibility as ORIGINTIME
is set just indirectly to time() and so it could be already one second
behind the INSTALLTIME of the initially installed package. I recommend
that we still do one final
On Thu, Jan 31, 2008, Jeff Johnson wrote:
On Jan 31, 2008, at 1:22 PM, Ralf S. Engelschall wrote:
On Thu, Jan 31, 2008, Jeff Johnson wrote:
On Jan 31, 2008, at 12:55 PM, Ralf S. Engelschall wrote:
[...]
We differ on whether the retrieval of originTime occurs before (as you
want) or after
On Thu, Jan 31, 2008, Jeff Johnson wrote:
On Jan 31, 2008, at 2:22 PM, Ralf S. Engelschall wrote:
On Thu, Jan 31, 2008, Jeff Johnson wrote:
[...]
Ok, my main concern is just about the fact that I do not wish to see
an offset between ORIGINTIME and INSTALLTIME on the initial package
On Jan 31, 2008, at 2:22 PM, Ralf S. Engelschall wrote:
On Thu, Jan 31, 2008, Jeff Johnson wrote:
[...]
Cool. I just see one small time difference possibility as ORIGINTIME
is set just indirectly to time() and so it could be already one
second
behind the INSTALLTIME of the initially
On Jan 31, 2008, at 2:41 PM, Ralf S. Engelschall wrote:
On Thu, Jan 31, 2008, Jeff Johnson wrote:
Equivalently, you could do your comparison against INSTALLTID
rather than
INSTALLTIME.
Sure, but INSTALLTIME is what people usually look at and if I print
ORIGINTIME (usually in rpm -qi
On Wed, Jan 30, 2008, Jeff Johnson wrote:
- propagate the time a package was first installed through upgrades.
[...]
Great! Many thanks, Jeff. That's certainly a lot better than my first
cut for such an implementation. I'll remove the code of my first cut
now. I also think ORIGINTIME is
On Jan 26, 2008, at 1:47 PM, Ralf S. Engelschall wrote:
On Sat, Jan 26, 2008, Jeff Johnson wrote:
Perhaps
Requires: verify(N) = E:V-R
will simplify some of your OpenPKG framework hardening.
Easy way to exercise the verify(...) probe is
mkdir -p /etc/rpm/sysinfo
echo
On Sat, Jan 26, 2008, Jeff Johnson wrote:
Perhaps
Requires: verify(N) = E:V-R
will simplify some of your OpenPKG framework hardening.
Easy way to exercise the verify(...) probe is
mkdir -p /etc/rpm/sysinfo
echo verify(zlib) /etc/rpm/sysinfo/Requirename
Return code is goofy
On Dec 29, 2007, at 4:45 PM, Jeff Johnson wrote:
(aside) Hmmm, perhaps enough time before rpm-5.0 to collect some
additional
keyring sources in rpmtsFindPubkey():
1) drill a FTS file walk through /etc/pki/rpm-gpg
2) slurp up ~/.gnupg/pubring.gpg
as I suggested privately a couple
On Dec 30, 2007, at 12:25 PM, Ralf S. Engelschall wrote:
On Sun, Dec 30, 2007, Jeff Johnson wrote:
On Dec 29, 2007, at 4:45 PM, Jeff Johnson wrote:
(aside) Hmmm, perhaps enough time before rpm-5.0 to collect some
additional
keyring sources in rpmtsFindPubkey():
1) drill a FTS file walk
Here's the QA coverage testing I've done:
I build in /X/src/wdj, change the path in what follows to taste.
1) run lib/genpgp.sh to generate test cases.
2) Add transaction dependencies to /etc/rpm/sysinfo.
My transaction dependencies looked like
signature(/X/src/wdj/lib/DSA.pem)
On Jul 17, 2007, at 4:29 PM, Mark Hatle wrote:
I agree, doesn't make sense to have multiple occurrences, but I
need to
be able to change the location based on run-time path. :P
Why? You plain and simply shouldn't be using per-system configuration
paths
if the paths need to change
Jeff Johnson wrote:
On Jul 17, 2007, at 4:29 PM, Mark Hatle wrote:
I agree, doesn't make sense to have multiple occurrences, but I need to
be able to change the location based on run-time path. :P
Why? You plain and simply shouldn't be using per-system configuration paths
if the paths
On Tue, Jul 17, 2007, Mark Hatle wrote:
Can we use the read-only macro syntax for these items? That way it's
set once early on and locked down?
[...]
How is this achieved? I see only something like .. in macros.c. Is
this the stuff you are talking about? Can you propose a particular
patch?
On Jul 17, 2007, at 4:37 PM, Ralf S. Engelschall wrote:
On Tue, Jul 17, 2007, Mark Hatle wrote:
Can we use the read-only macro syntax for these items? That way
it's
set once early on and locked down?
[...]
How is this achieved? I see only something like .. in macros.c. Is
this the stuff
Log:
- parameterize upgrade/obsoletes tag. Panu's Big Mistake imho.
This brings up an interesting question: At what point does
maintaining compatibility with rpm.org become counterproductive? This
patch may or may not be a big mistake (I really am not in a position
to say) but at some
28 matches
Mail list logo
