FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 09-17-2011, 01:36 PM
Richard Hughes
 
Default how to have yum prefer one dependency over others

On 17 September 2011 13:56, Kevin Kofler <kevin.kofler@chello.at> wrote:
> Richard Hughes wrote:
> And Python too, I suppose?

Sure. I'd welcome any python dudes to write a small program in
examples/ just to test if the GIR annotations are complete enough.

Richard.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-17-2011, 01:49 PM
Rahul Sundaram
 
Default how to have yum prefer one dependency over others

On 09/17/2011 06:44 PM, Michael Schroeder wrote:
> libzypp is actually a library on top of libsatsolver (now renamed to
> libsolv). If you want a lightweight package dependency solver you
> should probably use libsolv directly. (It also contains python
> bindings and a simple python demo program which uses a single rpm
> transaction to do the work.)

Does libsolv and libzypp have regular releases or is it just git
snapshots? I don't see a NEWS file or release notes anywhere


Rahul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-17-2011, 01:51 PM
Björn Persson
 
Default how to have yum prefer one dependency over others

Kevin Kofler wrote:
> The yum default provider picking logic has become so complex (and dependent
> on what the user happens to have already installed!)
[...]
> And while making a decision based on what
> the user has already installed may make sense from a user's perspective,
> from a developer's perspective, it's completely unacceptable because it
> means different users can get different dependencies dragged in by the
> same Requires, even with the same tool!

Do you *actually* mean that you would prefer a package manager that always
chooses the same package regardless of what the user has already installed? If
Gizmo requires frobnicator, which is provided by both Gnome-frobnicator and
KDE-frobnicator, and the user has only installed KDE, do you really want Gizmo
to pull in half of Gnome even though it works fine with KDE? I can't believe
that you would find that acceptable.

But if you actually want that – from a developer's perspective – then it's
dead simple to achieve: Just don't use virtual provides. Write "Requires:
Gnome-frobnicator" in Gizmo.spec. Problem solved; no need to replace the
package manager.

> If we want package maintainers to be able to actually choose what provider
> gets picked by default, all those complex heuristics must be replaced by
> something simple and dependable (e.g. 1. prefer same arch, 2. prever newest
> Provides version, 3. prefer shortest package name, 4. prefer first package
> name in the alphabet, period).

That algorithm would prefer KDE-frobnicator over Gnome-frobnicator, which is
undesired in Gnome-only installations, but it would prefer Gfrobnicator over
Kfrobnicator, which is undesired in KDE-only installations.

Björn Persson
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-17-2011, 02:23 PM
Panu Matilainen
 
Default how to have yum prefer one dependency over others

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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-17-2011, 02:58 PM
Rahul Sundaram
 
Default how to have yum prefer one dependency over others

On 09/17/2011 07:53 PM, Panu Matilainen wrote:
> 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

Ah I was hoping to come to this point. You are willing to merge a
depsolver directly in RPM? If so, have you looked at libsolv?

Rahul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-17-2011, 06:52 PM
Panu Matilainen
 
Default how to have yum prefer one dependency over others

On 09/17/2011 05:58 PM, Rahul Sundaram wrote:
>
>
> On 09/17/2011 07:53 PM, Panu Matilainen wrote:
>> 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
>
> Ah I was hoping to come to this point. You are willing to merge a
> depsolver directly in RPM?

With if's and but's ... yes. Otherwise there wouldn't have been much
point in bringing this up in the first place.

> If so, have you looked at libsolv?

Not in any depth (yet), but that'd be the obvious starting point. Based
on very cursory first looks, it appears spot-on in terms of abstraction
& layering.

- Panu -
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-17-2011, 08:51 PM
Jef Spaleta
 
Default how to have yum prefer one dependency over others

On Fri, Sep 16, 2011 at 11:58 AM, Richard Hughes <hughsient@gmail.com> wrote:

On 16 September 2011 20:46, Jef Spaleta <jspaleta@gmail.com> wrote:

>> Are you sure you didn't cut it down so much that you are hiding problems

>> that your depsolving rules don't solve well? * Did you throw out someone's

>> baby with all that bathwater?



Perhaps I did; the tests were made intentionally simple.


Richard, I'm stilling trying to figure out what your test repo actually is. As I said previously the git checkout of zif gives me a repodata directory that is not self-consistent with regard to repomd.xml checksums.* That's a problem.** I would appreciate it if you could perhaps publish a http url for your test repo data that you trust from a validity standpoint (not a safe to use standpoint) that I can then poke at with any number of tools that know how to interact with repomd data.* But right now, the breadcrumb starting point you gave me is a non-starter. If repomd and the sqlite db arent actually consistent, I can't do anything useful with that.


But putting that aside for a minute.* I'm interested in asking zif a series of more complicated real world Fedora repository questions to get a better understanding how your chosen scoring rules currently work in practise.

For example....

if I go to install paprefs package on an F15 system, under what circumstances will zif prefer to install kpackagekit* and in what circumstances will it prefer to install gnome-packagekit to meet the PackageKit-session-service requirement which they both provide?


If a system has KDE installed by not GNOME will zif choose to install kpackagekit?* If a system has GNOME installed but not KDE will zif choose gnome-packagekit?

If neither gnome or kde is installed...what does zif choose?* And yes these are valid questions as my F15 system doesn't need kpackagekit or gnome-packagekit installed for either desktop's normal operation or via a yum groupinstall* execution from a system that starts out with neither.




-jef

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-17-2011, 10:06 PM
Jef Spaleta
 
Default how to have yum prefer one dependency over others

On Sat, Sep 17, 2011 at 12:51 PM, Jef Spaleta <jspaleta@gmail.com> wrote:

But putting that aside for a minute.* I'm interested in asking zif a series of more complicated real world Fedora repository questions to get a better understanding how your chosen scoring rules currently work in practise.



zif as packaged in F15 is returning with

*zif_store_remote_get_provides: assertion `ZIF_IS_STORE_REMOTE (store)' failed

after this command

zif install paprefs

I was hoping the zif as packaged would be useful enough to to run transaction tests against real repos. It's looking like that's not the case.* If zif only seems to operate with your specially crafted stripped down repodata there isn't a lot to talk about at the moment.


-jef

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-18-2011, 08:27 AM
Richard Hughes
 
Default how to have yum prefer one dependency over others

On 17 September 2011 23:06, Jef Spaleta <jspaleta@gmail.com> wrote:
> zif as packaged in F15 is returning with

Zif in F15 is a really old version, and F16 is the first release where
I'm going to support zif. The latest upstream release is 0.2.3 and I
think the version in F15 is much older than that IIRC.

> I was hoping the zif as packaged would be useful enough to to run
> transaction tests against real repos. It's looking like that's not the
> case.* If zif only seems to operate with your specially crafted stripped
> down repodata there isn't a lot to talk about at the moment.

Naa, try the version of zif in F16, or grab the latest upstream SRPM
and rebuild it for f15 from here:
http://people.freedesktop.org/~hughsient/fedora/15/SRPMS/

I've been using zif exclusively day-to-day in F16 if that's a datapoint.

Richard.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-18-2011, 05:40 PM
Rahul Sundaram
 
Default how to have yum prefer one dependency over others

On 09/17/2011 01:02 AM, Richard Hughes wrote:
> On 16 September 2011 20:02, Richard W.M. Jones <rjones@redhat.com> wrote:
>> Is Zif a SAT solver?
> No, but I've been playing a few times with libsatsolver in the past year or so.

Since Panu Matilainen has said that he is willing to merge in a
depsolver in RPM directly, that seems to be the optimal choice at this
point. IMO, you should work with Michael Schrder and Panu Matilainen
to do that. If we (Red Hat, SUSE etc) have a fighting chance to
standardize on a single depsolver that is a really big win.

Rahul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 07:00 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org