On Tue, Oct 18, 2005 at 04:07:13AM +0100, Paul Jakma wrote:
On Mon, 17 Oct 2005, Michal Jaegermann wrote:
But that doesnt allow higher-level package management systems to spot such dependencies though.
How that would be really different?
Because the refcount would be a dependency, but that dependency isn't expressed anywhere, hence it's invisible to yum. The problem is similar to the dependency chain you noted in a previous mail, except your package management system can't see it and can't do anything about it.
X.i386 -> Y.i386 (X depends on Y) A.x86-64 -> Y.x86-64
No, this does not work that way. If you have A.i386 and A.x86_64 installed, and they do have common files, then an attempt to update only one from this pair ends up with conflicts. Seth already suggested that yum may have a "pair check" which woud allow either both updates or none.
X.x86-64 is to be upgraded, and depends on a newer version of Y.x86-64, which is pulled in and upgraded.
Here you really have A.i386, A.x86_64, and Common.noarch. Both As depend on Common. If you will try to update only, say, A.x86_64 this will force an update of Common which will cause "broken dependencies" error for a change unless you are updating A.i386 as well. So what is the real gain? Do you plan to loosen up dependencies on Common? That would open a gate to real horrors.
Michal
On Mon, 17 Oct 2005, Michal Jaegermann wrote:
No, this does not work that way. If you have A.i386 and A.x86_64 installed, and they do have common files, then an attempt to update only one from this pair ends up with conflicts.
Aha, and that's taken care of by rpmlib? Fine so.
Seth already suggested that yum may have a "pair check" which woud allow either both updates or none.
That would be useful I guess.
X.x86-64 is to be upgraded, and depends on a newer version of Y.x86-64, which is pulled in and upgraded.
Here you really have A.i386, A.x86_64, and Common.noarch. Both As depend on Common. If you will try to update only, say, A.x86_64 this will force an update of Common which will cause "broken dependencies" error for a change unless you are updating A.i386 as well. So what is the real gain? Do you plan to loosen up dependencies on Common? That would open a gate to real horrors.
No no.. read the mail you're replying to ;) - this is for the case of file refcounts in the rpm database, nothing to do with package splitting.
My suggestion was that this problem would be solved by enforcing "must be same version", and as you say above it already does, then there's no problem. So refcounts would indeed solve the problem.
The only issue left then would be directories like bin, libexec which unfortunately do not have bin64, libexec64 equivalents - a filesystem layout issue i guess. (But not a big issue, 99% of time you don't really care which arch a binary is, as long as it works. But be nice for testing to be able to have both arches of binaries installed).
Michal
regards,
No, this does not work that way. If you have A.i386 and A.x86_64 installed, and they do have common files, then an attempt to update only one from this pair ends up with conflicts. Seth already suggested that yum may have a "pair check" which woud allow either both updates or none.
Could I persuade you to open a bug about the above so I don't forget to look at it?
Thanks. -sv
On 18/10/05, seth vidal skvidal@phy.duke.edu wrote:
Could I persuade you to open a bug about the above so I don't forget to look at it?
This looks closely related to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164883 ... it all boils down to "please don't remove files that are still owned by another package".
On Tue, Oct 18, 2005 at 10:58:15AM +0100, Bill Crawford wrote:
On 18/10/05, seth vidal skvidal@phy.duke.edu wrote:
Could I persuade you to open a bug about the above so I don't forget to look at it?
This looks closely related to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164883 ... it all boils down to "please don't remove files that are still owned by another package".
Well, no, somewhat related but not exactly. I guess that we better be explicit about it.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171143
If a bug owner wishes to close that as a DUPLICATE we cannot prevent that. :-)
Michal
On Tue, 18 Oct 2005, Michal Jaegermann wrote:
On Tue, Oct 18, 2005 at 10:58:15AM +0100, Bill Crawford wrote:
On 18/10/05, seth vidal skvidal@phy.duke.edu wrote:
Could I persuade you to open a bug about the above so I don't forget to look at it?
This looks closely related to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164883 ... it all boils down to "please don't remove files that are still owned by another package".
Well, no, somewhat related but not exactly. I guess that we better be explicit about it. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171143 If a bug owner wishes to close that as a DUPLICATE we cannot prevent that. :-)
They are both dupes of https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119372 this bug has been open and high severity since march 2004.
-Dan