[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Spilt libperl from perl

David Woodhouse wrote:
On Mon, 2007-04-23 at 15:55 -0400, Bill Nottingham wrote:
Warren Togami (wtogami redhat com) said:
Any written plans of how exactly multilib will change for F8?


No concrete plans. One idea:

- Have all repos be single-arch. Those that want multilb subscribe to both
  repos, and have their packages determined by a yum plugin.

Amen. It would be nice if we could have them subscribe to the _normal_
i386 repo -- rather than having a separate repo with just a subset of
packages. The whole crappy 'has a -devel subpackage' heuristic can just
die, but this works _ONLY_ if we fix the tools to do the right thing
when the full set of secondary-arch packages is available.

For a start, that means fixing yum to refrain from installing both
versions when asked for packages by name. It should install only the
primary arch unless explicitly asked to do otherwise. I think that's the
same as bug #235756 which is filed against the installer. Should it be
moved to yum?

Secondly, we should kill the dirty hack in RPM which allows packages
with file conflicts in /usr/bin to be installed, with RPM silently
choosing one of the available files. The decision about what to install
should come from whatever's calling RPM; RPM shouldn't be
second-guessing. We should fix our packaging so that these file
conflicts don't exist -- packages with libraries which make sense on the
secondary arch should not also have executables in the same subpackage.
Bug #235757 covers this, as does the subject line of this thread.
We _might_ get away with just fixing RPM so that it generally does make
the right decision (in particular, installing 32-bit executables on
ppc64 and sparc64). But that's a crappy workaround typical of the kind
of half-arsed crap we've done for multilib in the past; RPM itself is
the wrong place to make such a decision. It lives at a higher level.
However, 'fixing' RPM might be the easiest option before F7, to fix the
perl breakage we've just introduced again -- but it's certainly not the
right answer in the long term.

  Pros: simple for repo creation
        allows users to customize what they want
Cons: the plugin could take a not-insignificant amount of cpu time/ram to run
        probably would need some core yum changes as well

I don't understand this plugin. What would it actually do?

If someone _wants_ something for the secondary arch, they'll install it
manually -- 'yum install firefox.i386', or 'yum install gdb.ppc64'.

Basically, there are two reasons that extensive multlib support is/was

1) Runtime - running ppc64 apps on ppc, i386 apps on x86_64

2) Development - developing i386 apps on a x86_64 box. Or ppc64 apps anywhere.

#2 has historically been a problem that multlib solved. In a fully open
Fedora world, it can be solved with mock (assuming we throw up a full
ppc64 tree somewhere).

Multilib hasn't actually solved it very reliably, in a world where so
many people make the mistake of using autoconf. I believe that
pkg-config, in particular, will also always get it wrong. (Bug #224037)

Mock solves it for packages, and yum's 'installroot' option can do it
for random other builds if necessary.

This leaves #1. You could certainly write algorithms to determine 'what
is a runtime lib' that will operate on any package set and decide what
to install. But, since any such algorithm will be iterating over the file
set, it's unlikely to be fast.

Again I think I'm missing something. We already have algorithms which
handle dependencies on runtime libs. If I 'yum install gdb.ppc64' on a
clean system where I've already done 'yum remove glibc.ppc64' to get rid
of all that unwanted crap in the default install, it knows that it needs
to install ncurses.ppc64 and glibc.ppc64. What do we need that's new?

The only problem I'm aware of with dependencies is the _manual_ deps,
where a package 'foo-devel' might say that it requires 'bar-devel', but
in fact it should require 'bar-devel.%{ARCH}'. Because otherwise you get
stuff like pango-devel.i386 being satisfied by the existence of
cairo-devel.x86_64. Which doesn't actually work when you come to build
it. Bug #235755.

What can I say, all this sounds like I could have written this myself, so this gets a huge +1 from me. BTW, I think bug 235755 is a dup of a bug of mine (filed against rpm).



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]