On Sun, 16 Oct 2005, Michal Jaegermann wrote:
I am curious how you would propose to resolve that taking into
account all existing packages and this detail that people making
original packages may be often unaware of the issue and even if
they are they may not have suitable installations for testing.
Multiply that by 'extras', external repositories, and so on. If
you will get strict here then resulting pains will surely far
exceed your worst current hiccups.
True.
AFAICT dependencies are really "swallowed" during an installation
if files in question are the same - which is easy to test. At
least if the whole concept is not buggy It appears that you were
bitten by something else or you run into some traps in testing but
that what testing is for.
It was FC3testX I think. If it's now as you describe, then it's sane
- within the constraints of not wanting to change too much to
accomodate multi-arch.
There are obviously open problems in a multilib packages _removal_
but this is not exactly the same thing.
Indeed.
Ideally you'd split off the docs, etc into -common.noarch packages
(lot of work) or add true multi-arch capability to rpm packages, such
that a package would mark each file individually with it's
architecture. Then possibilities open up like:
- x86 (or just x86-64) packages contain both common, i386 and x86_64
arch files and one could install either one or both of the sets of
arch-dependent files.
- the x86-64 package contains /just/ the x86-64 files, depends on the
full package (whose i386 arch files are marked as such) and one
uses the conglomeration of the two packages to install x86-64 (and
also i386, if one desires)
Obviously, there's a space cost. But it solves the removal issues,
and it's how other systems which have supported multi-arch for *far*
longer than Linux have done it (IRIX), and it worked nicely there.
(Also makes cross compiling very easy, eg installing x86-64 libs on
i386 to allow compilation of x86-64 binaries).
But it'd need a lot of reworking of packages. :( Till then the
"swallow same file" hack is acceptable I guess, if it does indeed now
check the files are actually the same.
Thanks for clarifying this for me.
Michal
regards,
--
Paul Jakma paul@xxxxxxxx paul@xxxxxxxxx Key ID: 64A2FF6A
Fortune:
You could live a better life, if you had a better mind and a better body.
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list