On 09/16/2011 11:53 PM, Michael Schwendt wrote:
> On Fri, 16 Sep 2011 13:49:36 -0400, SV (seth) wrote:
>
>> There are still a largish number of packages out there that have things
>> like:
>>
>> Requires: foo
>>
>> where they really want:
>> Requires: foo(64bit)
>
> Fixing this in some packages is not entirely easy.
> Why? Because whereas the %{name}%{?_isa} Provides are automatic,
>
> $ rpm -q --provides glib2|grep ' = '
> glib2 = 2.29.90-1.fc16
> glib2(x86-64) = 2.29.90-1.fc16
>
> some packages depend on virtual capabilities in order to make external
> dependencies much more strict. E.g.
>
> Provides: foo(abi) = 5
>
> These are not arch-specific. How to convert from what we have so far to
> the new era of adding an explicit %{?_isa} everywhere? Where we have a
>
> Requires: foo(abi) = 5
>
> we cannot simply add an explicit arch-specific dep on the package name,
>
> Requires: foo(abi) = 5
> Requires: foopkg%{?_isa}
>
> can we?
>
> What happens if foopkg is upgraded to foo(abi) = 6? Yum will still run a
> cross-arch search for a foo(abi) provider and on x86_64 may find it in an
> older i686 package that's still in the repo, too.
>
> It seems we need to make the full show arch-specific:
>
> Provides: foo(abi)%{?_isa} = 5
> and
> Requires: foo(abi)%{?_isa} = 5
>
> For released dists that will break dependencies and require rebuilds.
For manually added provides such a thing can be easily done gradually
without flag-days: add an isa-specific provides along the non-isa
version, adjust requiring packages when suitable and then finally remove
the non-isa provides when nothing needs them anymore.
Of course its not always that simple: There are various cases where the
arch/isa simply isn't known, for example pkg-config requires generation
has no way of knowing whether a particular dependency is arch-dependent
or not. Python with its ambiguous use of /usr/lib is another pile of
fun, etc.
%{_isa} is as klunky as it is because it's just a stupid build-time
macro which allows *somehow* expressing the arch-dependency without
changes to the entire repository + packaging toolchain, including
buildsys builders which are pretty much by definition always running
much older versions of rpm & yum (yes they had a custom-built newer rpm
for a period of time when the builders were RHEL 5, but I doubt anybody
would be too happy to repeat that experience).
Rpm could certainly be taught nicer mechanisms to permit packages to
specify whether their dependency can be satisfied by a package of
different arch/isa-style thingie (and various other tricks), but with
everybody doing their own depsolving without ever really asking from rpm
(heck, one of the points behind the repodata was to get rpm OUT of the
depsolving loop), anything like this requires changing not just the
rather frozen-format repodata but teaching the same things over and over
againt o different tools. And because its so bloody painful nobody
really bothers.
The near-flamefest on this thread over whose depsolver is the best is
largely besides the point: in a perfect world there would be just one
Grand Unified Depsolver (library) that everything including rpm itself
would use. And in order for rpm to be able to use it, it'd have to be
implemented in C. Whether its *in* rpm or something external (such as
libsatsolver) is a different question entirely.
Now there's a nice little pet-project for somebody ;)
- Panu -
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
