11:33 a.m.
Hi all,
Hope it's okay to ask for general RPM/Yum advice here.
We have several packages that require grid CA certificates to be
installed. There are multiple sets of grid certificates, and we want to
leave up to individual sites which set to install. We also want to give
the sites the option to install none of them if they know what they are
doing and want to manage certificates by themselves.
So what we do is we add to each package that requires grid certificates
a 'Requires: grid-certificates' line, and to each package that provides
grid certificates a 'Provides: grid-certificates' line. We also create a
dummy package, called 'no-ca-certs' that does nothing but provide the
grid-certificates dependency.
We want to set it up so that one of these certs packages is preferred
over the others, so that if the user doesn't explicitly choose which one
to install, then that package is installed by default. How can we do
that? We tried having the packages provide different versions of the
grid-certificates virtual dependency (i.e. no-ca-certs would have
'Provides: grid-certificates = 1', osg-ca-certs (which we prefer) would
have 'Provides: grid-certificates = 2') in hopes that yum would pick the
one with the highest version, but it didn't help. Any ideas?
Thanks,
-Matyas Selmeci
11:36 a.m.
On Fri, 2011-09-16 at 11:33 -0500, Matyas Selmeci wrote:
Hi all,
Hope it's okay to ask for general RPM/Yum advice here.
We have several packages that require grid CA certificates to be
installed. There are multiple sets of grid certificates, and we want to
leave up to individual sites which set to install. We also want to give
the sites the option to install none of them if they know what they are
doing and want to manage certificates by themselves.
So what we do is we add to each package that requires grid certificates
a 'Requires: grid-certificates' line, and to each package that provides
grid certificates a 'Provides: grid-certificates' line. We also create a
dummy package, called 'no-ca-certs' that does nothing but provide the
grid-certificates dependency.
We want to set it up so that one of these certs packages is preferred
over the others, so that if the user doesn't explicitly choose which one
to install, then that package is installed by default. How can we do
that? We tried having the packages provide different versions of the
grid-certificates virtual dependency (i.e. no-ca-certs would have
'Provides: grid-certificates = 1', osg-ca-certs (which we prefer) would
have 'Provides: grid-certificates = 2') in hopes that yum would pick the
one with the highest version, but it didn't help. Any ideas?
Here is how yum does comparison between multiple package providing the
same thing:
http://yum.baseurl.org/wiki/CompareProviders
if you follow that as your guide you can probably make one of them be
the default choice.
-sv
12:26 p.m.
On 16 September 2011 17:36, seth vidal <skvidal(a)fedoraproject.org> wrote:
Here is how yum does comparison between multiple package providing
the
same thing:
http://yum.baseurl.org/wiki/CompareProviders
I don't think that works for all cases; surely "grid-certificates = 2"
wins over "grid-certificates = 1" in all cases? It's certainly better
than relying on the length of the package name or alphabetical
ordering...
In Zif, I'm doing something like:
* Filter by best arch
* Filter by depend version
* Filter by native arch
* Filter by smallest name
* Filter by newest
...and this seems to work well as normal people don't want to drag
non-native architecture packages onto their system for an update and
want to follow the latest provide version (even if that means
installing additional deps). The current logic where yum wants to
install a hundred i686 packages on my x86_64 box when the repos get a
bit screwy doesn't seem to work very well in my opinion.
Richard.
12:31 p.m.
On Fri, Sep 16, 2011 at 7:26 PM, Richard Hughes <hughsient(a)gmail.com> wrote:
On 16 September 2011 17:36, seth vidal
<skvidal(a)fedoraproject.org> wrote:
> Here is how yum does comparison between multiple package providing the
> same thing:
> http://yum.baseurl.org/wiki/CompareProviders
<snip>
In Zif, I'm doing something like:
...
I don't particularly care how the best provider is selected, but
having different tools use different rules is not acceptable.
Mirek
12:43 p.m.
On Fri, 2011-09-16 at 19:31 +0200, Miloslav Trmač wrote:
On Fri, Sep 16, 2011 at 7:26 PM, Richard Hughes
<hughsient(a)gmail.com> wrote:
> On 16 September 2011 17:36, seth vidal <skvidal(a)fedoraproject.org> wrote:
>> Here is how yum does comparison between multiple package providing the
>> same thing:
>> http://yum.baseurl.org/wiki/CompareProviders
<snip>
> In Zif, I'm doing something like:
...
I don't particularly care how the best provider is selected, but
having different tools use different rules is not acceptable.
having different tools is not acceptable. Especially when one of them is
not even remotely covering the use cases of our actual users.
I think I'm going to suggest to fesco that all non-yum depsolvers be
removed from the distribution. It just creates more work than it does
value.
If someone wants to ship a depsolver in their own repo on fedorapeople,
that's fine but providing it in the distro is just a mistake.
-sv
1:42 p.m.
On 16 September 2011 18:43, seth vidal <skvidal(a)fedoraproject.org> wrote:
having different tools is not acceptable. Especially when one of them
is
not even remotely covering the use cases of our actual users.
Installing 205 new i686 packages when updating the system is not acceptable.
I think I'm going to suggest to fesco that all non-yum depsolvers
be
removed from the distribution. It just creates more work than it does
value.
Ha! That's really funny, and it's just made my evening. While you're
asking fesco, can you also ask them to remove KDE and XFCE as well
please.
There's really nothing special about a package manager I assure you.
Richard.
1:45 p.m.
On Fri, Sep 16, 2011 at 8:42 PM, Richard Hughes <hughsient(a)gmail.com> wrote:
> I think I'm going to suggest to fesco that all non-yum
depsolvers be
> removed from the distribution. It just creates more work than it does
> value.
Ha! That's really funny, and it's just made my evening. While you're
asking fesco, can you also ask them to remove KDE and XFCE as well
please.
There's really nothing special about a package manager I assure you.
How about the 1126 members of the "packager" group - i.e. most of us -
that would have to create and maintain packages compatible with two
different systems?
Mirek
1:48 p.m.
2011/9/16 Miloslav Trmač <mitr(a)volny.cz>:
How about the 1126 members of the "packager" group - i.e.
most of us -
that would have to create and maintain packages compatible with two
different systems?
That's nonsense, sorry. Zif is quite capable of using the same
metadata as yum and performing the same function with the same set of
packages.
Richard.
1:52 p.m.
On Fri, 2011-09-16 at 19:48 +0100, Richard Hughes wrote:
2011/9/16 Miloslav Trmač <mitr(a)volny.cz>:
> How about the 1126 members of the "packager" group - i.e. most of us -
> that would have to create and maintain packages compatible with two
> different systems?
That's nonsense, sorry. Zif is quite capable of using the same
metadata as yum and performing the same function with the same set of
packages.
Not if Zif is coming up with different results for providers.
Since you've developed entirely in your own silo I suspect you've failed
to discover the bevy of edge and corner cases which plague package
management.
You should consider working with the packaging team. They have a
combined experience and history of rpm and yum with millions and
millions of installs and users of each to draw from.
-sv
2:07 p.m.
On Fri, Sep 16, 2011 at 10:48 AM, Richard Hughes <hughsient(a)gmail.com>wrote:
That's nonsense, sorry. Zif is quite capable of using the same
metadata as yum and performing the same function with the same set of
packages.
It's also capable of making different decisions? Isn't that your point?
So
far I get the feeling you are unhappy about one or more specific yum
transaction depsolving solultions and you feel you have come up with a more
optimal depsolving policy that results in a different transaction solution
in some cases. Specific transactions I'm not privy to as so far in this
particular discussion there hasn't been a mention of a repeatable test
methodology that you used in constructing your more optimal depsolver. A
methodology I could use to then verify suboptimal performance of any number
of depsolving policies for myself in my own testing.
And since we seem to only be talking about optimization of policy rules
(which could and probably should equally apply to all depsolvers in Fedora)
shouldn't it be possible to encode your possibly more optimal policy rules
as a yum plugin specifically so we can do some testing without conflating
the depsolving policy optimization with other tehcnical changes? If your
approach to depsolving really is better, we should be able to test that
systematically with existing repo data transactions and build a case for a
depsolving rule change as part of yum's evolution.
I'd have no problem seeing individuals feeling empowered to play around with
the depsolving scoring in anticipation of them discussing potentially
beneficial changes in the scoring policy with the people who have put effort
into the one we are currently using, I'm pretty sure all of that can be
done in the context of yum as is, without having to introduce a completely
new codebase which starts out of the gate with a different depsolving
scoring policy.
-jef
2:10 p.m.
On Fri, 2011-09-16 at 11:07 -0800, Jef Spaleta wrote:
> And since we seem to only be
talking about optimization of policy
> rules (which could and probably should equally apply to all depsolvers
> in Fedora) shouldn't it be possible to encode your possibly more
> optimal policy rules as a yum plugin specifically so we can do some
> testing without conflating the depsolving policy optimization with
> other tehcnical changes? If your approach to depsolving really is
> better, we should be able to test that systematically with existing
> repo data transactions and build a case for a depsolving rule change
> as part of yum's evolution.
As a point of fact we added a depsolving plugin hook for
compare_providers over a year ago into the yum codebase.
Specifically so anyone could do fun and exciting additions to
compare_providers and/or request user input on the decisions.
-sv
2:18 p.m.
On Fri, Sep 16, 2011 at 11:10 AM, seth vidal <skvidal(a)fedoraproject.org>wrote:
As a point of fact we added a depsolving plugin hook for
compare_providers over a year ago into the yum codebase.
Specifically so anyone could do fun and exciting additions to
compare_providers and/or request user input on the decisions.
Excellent.
If Richard were to code up his alternative depsolver using those hooks. I'm
more than happy to log all my yum transactions using the default and
alternative depsolving rules so we can get some concrete examples of
transaction divergence over a range of interactions.
-jef
2:22 p.m.
On 16 September 2011 20:07, Jef Spaleta <jspaleta(a)gmail.com> wrote:
A methodology I could use to then verify suboptimal performance of
any number
of depsolving policies for myself in my own testing.
This is what I've come up with already:
https://github.com/hughsie/zif/tree/master/data/tests/transactions
Richard
2:32 p.m.
On Fri, Sep 16, 2011 at 11:22 AM, Richard Hughes <hughsient(a)gmail.com>wrote:
This is what I've come up with already:
https://github.com/hughsie/zif/tree/master/data/tests/transactions
Okay just to make sure I understand what the manifest info is
local: the package installed
remote: the available provider(s) that satify the transaction requirements?
transaction: command performed
config: system state like what arch we are pretending to be at the moment?
For these tests... what is the remote repository metadata that you are
using? Is is a cutdown set of repo data or is it a snapshot of a real fedora
tree at some moment in time?
-jef
2:35 p.m.
On 16 September 2011 20:32, Jef Spaleta <jspaleta(a)gmail.com> wrote:
local: the package installed
Yup, the "installed" store.
remote: the available provider(s) that satify the transaction
requirements?
The packages available in remote stores.
transaction: command performed
Yup.
config: system state like what arch we are pretending to be at the
moment?
Right, and other stuff like skip_broken or exact_arch and that kind of thing.
For these tests... what is the remote repository metadata that you
are
using? Is is a cutdown set of repo data or is it a snapshot of a real fedora
tree at some moment in time?
The transactions are all taken in spirit from real problems, but made
as simple as possible. The repodata is all cut down to the bare
minimum.
Checkout zif, and run "make check" and you'll see everything that's
done.
Richard.
2:38 p.m.
On Fri, Sep 16, 2011 at 11:35 AM, Richard Hughes <hughsient(a)gmail.com>wrote:
The transactions are all taken in spirit from real problems, but made
as simple as possible. The repodata is all cut down to the bare
minimum.
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?
-jef
2:46 p.m.
On Fri, Sep 16, 2011 at 11:38 AM, Jef Spaleta <jspaleta(a)gmail.com> wrote:
On Fri, Sep 16, 2011 at 11:35 AM, Richard Hughes <hughsient(a)gmail.com>wrote:
>
> The transactions are all taken in spirit from real problems, but made
> as simple as possible. The repodata is all cut down to the bare
> minimum.
>
>
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?
If I wanted to run the same transaction tests under current yum using your
cutdown repodata directory and point yum to it?
I'm assuming you've done this already. are there particular test
transactions where yum comes up with a different solution than zif using
your cutdown repodata that you would like to draw my attention to?
-jef
2:58 p.m.
On 16 September 2011 20:46, Jef Spaleta <jspaleta(a)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.
If I wanted to run the same transaction tests under current yum using
your
cutdown repodata directory and point yum to it?
Sure, I guess you could write some python for that. I'm not really a
python dude.
I'm assuming you've done this already. are there particular
test
transactions where yum comes up with a different solution than zif using
your cutdown repodata that you would like to draw my attention to?
No, I've not, but I would be very surprised if those simple
transaction results differed. The way the results would differ is if
you setup a fake repo that's intentionally broken, and switched on
skip_broken.
Richard.
3:42 p.m.
On Fri, Sep 16, 2011 at 11:58 AM, Richard Hughes <hughsient(a)gmail.com>wrote:
> I'm assuming you've done this already. are there particular test
> transactions where yum comes up with a different solution than zif using
> your cutdown repodata that you would like to draw my attention to?
No, I've not, but I would be very surprised if those simple
transaction results differed. The way the results would differ is if
you setup a fake repo that's intentionally broken, and switched on
skip_broken.
Okay, then I'm confused about your initial salvo into this thread. And
I'm
further puzzled by your statement:
"Installing 205 new i686 packages when updating the system is not
acceptable."
if you haven't actually tested your alternative scoring logic against a case
complex enough for yum to pull in 205 i686 packages where zif does
not...then isn't all of this putting the card well ahead of the horse?
So let me back up and ask some more fundamental question.
If you've only tested your alternative scoring logic on simple transactions
which you don't expect yum and zif to differ, what is the rationale for
using different scoring logic?
Is this just a situation where you were working under incorrect information
concerning what yum's scoring logic actually does?
I'm looking for any theoretical or real depsolving transaction situation
(that I can retest locally) where you feel the scoring rules that zif is
using provides a more optimal transaction solution than the rules were are
currently using in yum and anaconda right now.
I think seth has already pointed out some important situations in his
detailed explanation of the scoring in use now where your cutdown repodata
test probably isn't providing you the transaction solution confidence users
will need.
-jef
3:51 p.m.
On Fri, Sep 16, 2011 at 11:58 AM, Richard Hughes <hughsient(a)gmail.com>wrote:
On 16 September 2011 20:46, Jef Spaleta <jspaleta(a)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
5:06 p.m.
On Sat, Sep 17, 2011 at 12:51 PM, Jef Spaleta <jspaleta(a)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
3:27 a.m.
On 17 September 2011 23:06, Jef Spaleta <jspaleta(a)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.
5:44 p.m.
Richard Hughes wrote:
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 submitted a Koji scratch build of zif-0.2.4-0.78.20110918git for F15:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3359296
It's a scratch build, so it will NOT be pushed to any repository (download
the build output directly from Koji if you want it) and it will expire in 2
weeks.
I might set up a zif backport repository for F15 on repos.fedorapeople.org
like I did with gtk3 for F14 if there's interest and if you (Richard Hughes)
are OK with it.
Kevin Kofler
7:46 p.m.
I wrote:
Richard Hughes wrote:
> 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 submitted a Koji scratch build of zif-0.2.4-0.78.20110918git for F15:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3359296
It's a scratch build, so it will NOT be pushed to any repository (download
the build output directly from Koji if you want it) and it will expire in
2 weeks.
I might set up a zif backport repository for F15 on repos.fedorapeople.org
like I did with gtk3 for F14 if there's interest and if you (Richard
Hughes) are OK with it.
Well, looks like we also need a rebuild of PackageKit-zif against the new
soname (libzif.so.3, the package in F15 is built against libzif.so.2), so I
think the repo is the best solution if we want people to be able to test
this. Richard, what do you think?
Kevin Kofler
2:02 a.m.
On 19 September 2011 01:46, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Well, looks like we also need a rebuild of PackageKit-zif against the
new
soname (libzif.so.3, the package in F15 is built against libzif.so.2), so I
think the repo is the best solution if we want people to be able to test
this. Richard, what do you think?
This is why I didn't backport the new zif to F15.
If you're confident doing the PK and zif rebuild for F15 at the same
time then I'm happy just to stick it in F15 properly rather than
having a separate repo. I didn't trust myself enough to not break PK
in a stable release, although it would only affect people with
PackageKit-zif already installed.
I'm okay with either solution. Thanks.
Richard.
11:41 a.m.
On Sun, Sep 18, 2011 at 2:44 PM, Kevin Kofler <kevin.kofler(a)chello.at>wrote:
Richard Hughes wrote:
> 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 submitted a Koji scratch build of zif-0.2.4-0.78.20110918git for F15:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3359296
Hey, Kevin and Richard
I've installed this zif from koji and I'm still not able to complete a "zif
install paprefs" transaction with realworld F15 configured public repository
set, whereas all the yum based tools: yum. repoquery etc... complete as
expected.
Here is what yum repolist returns
repo id repo
name
status
adobe-linux-i386 Adobe Systems
Incorporated 18
fedora Fedora 15 -
x86_64 24,085
google-musicmanager
google-musicmanager
1
google-talkplugin
google-talkplugin
1
openshift-express
Openshift-express
1
rpmfusion-free RPM Fusion for
Fedora 15 - Free 438
rpmfusion-free-updates RPM Fusion for
Fedora 15 - Free - Updates 287
rpmfusion-nonfree RPM Fusion for
Fedora 15 - Nonfree 179
rpmfusion-nonfree-updates RPM Fusion for
Fedora 15 - Nonfree - Updates 120
updates Fedora 15 - x86_64
- Updates 6,408
updates-testing Fedora 15 - x86_64
- Test Updates 1,239
Guys what's going on with zif?
-jef
12:33 p.m.
On 19 September 2011 17:41, Jef Spaleta <jspaleta(a)gmail.com> wrote:
I've installed this zif from koji and I'm still not able to
complete a "zif
install paprefs" transaction with realworld F15 configured public repository
set, whereas all the yum based tools: yum. repoquery etc... complete as
expected.
Guys what's going on with zif?
Can you open a ticket on Red Hat bugzilla please, component "zif" and
attach the output of "zif install paprefs -v"
I've not tested zif on F15 in a loooong time and it's probably just a
trivial bug. Thanks.
Richard.
2:55 p.m.
On Mon, Sep 19, 2011 at 9:33 AM, Richard Hughes <hughsient(a)gmail.com> wrote:
Can you open a ticket on Red Hat bugzilla please, component
"zif" and
attach the output of "zif install paprefs -v"
I've not tested zif on F15 in a loooong time and it's probably just a
trivial bug. Thanks.
Filed : Bug 739701 <https://bugzilla.redhat.com/show_bug.cgi?id=739701>
-jef
3:14 p.m.
On Fri, Sep 16, 2011 at 11:35 AM, Richard Hughes <hughsient(a)gmail.com>wrote:
The transactions are all taken in spirit from real problems, but
made
as simple as possible. The repodata is all cut down to the bare
minimum.
Uhm your repomd.xml in your repodata directory in git appears to have the
wrong sha256 checksum for the primary db that you are using by default. I
want to make sure I'm using the correct self-consistent cutdown test repo as
your test transactions are not repeatable in a real word fedora repo..
-jef
8:13 p.m.
Miloslav Trmač wrote:
On Fri, Sep 16, 2011 at 8:42 PM, Richard Hughes
<hughsient(a)gmail.com>
wrote:
>> I think I'm going to suggest to fesco that all non-yum depsolvers be
>> removed from the distribution. It just creates more work than it does
>> value.
>
> Ha! That's really funny, and it's just made my evening. While you're
> asking fesco, can you also ask them to remove KDE and XFCE as well
> please.
>
> There's really nothing special about a package manager I assure you.
How about the 1126 members of the "packager" group - i.e. most of us -
that would have to create and maintain packages compatible with two
different systems?
The yum default provider picking logic has become so complex (and dependent
on what the user happens to have already installed!) that we effectively
have to treat it as random and non-deterministic anyway. So if some other
tool makes another random choice, that won't really change all that much.
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). (Also note that I intentionally use a linear
decision tree, not scoring. If you weigh the criteria against each other,
it's much harder to be certain of what will happen than if you just make the
decision based on the highest-priority criterion only.) What zif is doing is
a step in the right direction there, and for the consistency issue, it's yum
that should be fixed, not zif. If the algorithm comes up with the wrong
result, we need to fix the packages, not the algorithm (and this is the
mistake yum made). 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!
Kevin Kofler
8:51 a.m.
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
7:40 p.m.
Björn Persson wrote:
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.
The use case I have in mind, which is a real-world case, is this:
phonon Requires: phonon-backend
phonon-backend-* Provides: phonon-backend
phonon-backend-* Requires: phonon
I want any random phonon-backend-* to satisfy the dependency, HOWEVER, I
want installing phonon when it previously wasn't installed to always drag in
phonon-backend-gstreamer, our default backend and the one working the best,
not some random backend which happens to have fewer dependencies. Yum's
convoluted logic is making it basically impossible to do that, and in fact,
on the RPM Fusion builders, phonon-backend-vlc is selected instead, which is
always fun because it means vlc's regular broken dependencies can break
builds of anything KDE-related in RPM Fusion. (I had a k3b-extras-freeworld
build break because of this very issue.) I guess users installing KDE with
RPM Fusion Free enabled will also get the VLC backend by default, which is
not what we want.
We really need a way to be able to specify an explicit default which is used
independently of what the user has installed, even if we don't always use it
(I can see the case of gnome-* vs. kde-*); the version number of the
Provides would be one solution. ("Shortest name" or "first in the
alphabet"
is just a hack, which forces silly things like using "phonon-bknd-gst", so I
don't think that's a good way to make the decision, though even that was
better than what we have now, which is almost unpredictable.)
Kevin Kofler
8:32 p.m.
On Mon, Sep 19, 2011 at 02:40:30AM +0200, Kevin Kofler wrote:
We really need a way to be able to specify an explicit default which
is used
independently of what the user has installed, even if we don't always use it
(I can see the case of gnome-* vs. kde-*); the version number of the
Provides would be one solution. ("Shortest name" or "first in the
alphabet"
is just a hack, which forces silly things like using "phonon-bknd-gst", so I
don't think that's a good way to make the decision, though even that was
better than what we have now, which is almost unpredictable.)
Debian policy is that any virtual dependencies must also have an
explicit dependency. In your case it would be something like
Requires: phonon-backend-gstreamer | phonon-backend
If the virtual dependency is already satisfied then nothing happens,
but if not phonon-backend-gstreamer would be used to satisfy it. This
works fine for package dependencies, but I'd imagine file-based
dependencies would make things more awkward.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
6:46 a.m.
On Mon, Sep 19, 2011 at 01:00:35PM +0200, Kevin Kofler wrote:
Matthew Garrett wrote:
> Debian policy is that any virtual dependencies must also have an
> explicit dependency. In your case it would be something like
>
> Requires: phonon-backend-gstreamer | phonon-backend
Unfortunately, RPM does not support this idiom.
I know. I'm just pointing out that this is a problem that's been solved
in the past.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
10:46 a.m.
On Mon, Sep 19, 2011 at 1:00 PM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Matthew Garrett wrote:
> Debian policy is that any virtual dependencies must also have an
> explicit dependency. In your case it would be something like
>
> Requires: phonon-backend-gstreamer | phonon-backend
Unfortunately, RPM does not support this idiom.
<trolling>
Why don't you just replace rpm, with deb too, while you are at it ?
</trolling>
11:11 a.m.
On Mon, Sep 19, 2011 at 5:46 PM, tim.lauridsen(a)gmail.com
<tim.lauridsen(a)gmail.com> wrote:
On Mon, Sep 19, 2011 at 1:00 PM, Kevin Kofler
<kevin.kofler(a)chello.at> wrote:
> Matthew Garrett wrote:
>> Debian policy is that any virtual dependencies must also have an
>> explicit dependency. In your case it would be something like
>>
>> Requires: phonon-backend-gstreamer | phonon-backend
>
> Unfortunately, RPM does not support this idiom.
>
<trolling>
Why don't you just replace rpm, with deb too, while you are at it ?
</trolling>
Well as long as the tools we are talking about
1) Do use rpm
2) Do valid dependency resolution (i.e not --nodeps or something like that)
I don't see why we shouldn't allow them.
lets say
yum install foo does:
foo, bar1, baz1
$nonyumtool install foo does:
foo, bar2, baz2
Both bar1/baz1 and bar2/baz2 are valid deps for foo (both statify the
dependency).
So why would it matter what in the end?
If that causes "bugs" then either of the deps are wrong (and the
packages in question ought to be fixed).
So I don't get what this flamefest is all about ...
8:47 a.m.
On Mon, 2011-09-19 at 18:11 +0200, drago01 wrote:
On Mon, Sep 19, 2011 at 5:46 PM, tim.lauridsen(a)gmail.com
<tim.lauridsen(a)gmail.com> wrote:
> On Mon, Sep 19, 2011 at 1:00 PM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
>> Matthew Garrett wrote:
>>> Debian policy is that any virtual dependencies must also have an
>>> explicit dependency. In your case it would be something like
>>>
>>> Requires: phonon-backend-gstreamer | phonon-backend
>>
>> Unfortunately, RPM does not support this idiom.
>>
> <trolling>
> Why don't you just replace rpm, with deb too, while you are at it ?
> </trolling>
Well as long as the tools we are talking about
1) Do use rpm
2) Do valid dependency resolution (i.e not --nodeps or something like that)
I don't see why we shouldn't allow them.
lets say
yum install foo does:
foo, bar1, baz1
$nonyumtool install foo does:
foo, bar2, baz2
Both bar1/baz1 and bar2/baz2 are valid deps for foo (both statify the
dependency).
So why would it matter what in the end?
I guess the discussion is more about if you extend your scenario this
way (and I'm picking DEs only as an example here, please don't start a
flamefest about it, there are worthier causes):
- bar1/baz1 are GNOME providers of bar/baz
- bar2/baz2 are KDE/XFCE/other DE providers of bar/baz
- GNOME is installed on the machine, but not KDE/XFCE/other DE
In that case, you really want bar1/baz1 to be installed over the others
(which would pull in KDE/XFCE/other DE base libraries), even though the
other solution is correct dependency-wise.
A much trickier scenario would be if a (say multi-user, terminal server)
machine had both GNOME and KDE/XFCE/other DE installed: it may be
desirable to install both bar1/baz1 and bar2/baz2 so users of each DE
got their own native providers of bar/baz. I don't think we can describe
this intended outcome in ways of RPM requirements today, and it'd
probably be pretty hard even with Suggests/Recommends because it partly
depends on policy, i.e. what the admin wants. Nothing in the system can
tell the package manager right now if which of these options should be
used in this case.
Nils
--
Nils Philippsen "Those who would give up Essential Liberty to purchase
Red Hat a little Temporary Safety, deserve neither Liberty
nils(a)redhat.com nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
1:04 a.m.
On Mon, 2011-09-19 at 18:11 +0200, drago01 wrote:
So I don't get what this flamefest is all about ...
catching up on the thread at a remove of a couple of weeks, I'd say
mostly it's about giant, swinging....egos.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
12:04 p.m.
tim.lauridsen(a)gmail.com wrote:
<trolling>
Why don't you just replace rpm, with deb too, while you are at it ?
</trolling>
* Because dpkg is missing essential RPM features (e.g. file and soname
dependencies).
* Because replacing RPM essentially means creating a new distribution,
whereas the depsolver can be easily replaced, and in fact you can even use
multiple depsolvers on the same machine at the same time (well, you can't do
the transactions simultaneously, obviously, but you can have both installed
and use one or the other as you see fit).
Sorry, couldn't resist feeding the troll. ;-)
Kevin Kofler
4:59 a.m.
On Mon, Sep 19, 2011 at 02:40:30AM +0200, Kevin Kofler wrote:
The use case I have in mind, which is a real-world case, is this:
phonon Requires: phonon-backend
phonon-backend-* Provides: phonon-backend
phonon-backend-* Requires: phonon
I want any random phonon-backend-* to satisfy the dependency, HOWEVER, I
want installing phonon when it previously wasn't installed to always drag in
phonon-backend-gstreamer, our default backend and the one working the best,
not some random backend which happens to have fewer dependencies. Yum's
convoluted logic is making it basically impossible to do that, and in fact,
on the RPM Fusion builders, phonon-backend-vlc is selected instead, which is
always fun because it means vlc's regular broken dependencies can break
builds of anything KDE-related in RPM Fusion. (I had a k3b-extras-freeworld
build break because of this very issue.) I guess users installing KDE with
RPM Fusion Free enabled will also get the VLC backend by default, which is
not what we want.
Sounds like you want weak dependencies (i.e. "Suggests" et al).
Cheers,
Michael.
--
Michael Schroeder mls(a)suse.de
SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
6:02 a.m.
Michael Schroeder wrote:
Sounds like you want weak dependencies (i.e. "Suggests" et
al).
In this case, I think disjunctive dependencies (default | virtual), as
Matthew Garrett pointed out, are the right solution, not soft dependencies
(though those would also be nice).
Kevin Kofler
10:51 a.m.
Kevin Kofler wrote on Mon, Sep 19, 2011 at 01:02:26PM +0200:
Michael Schroeder wrote:
> Sounds like you want weak dependencies (i.e. "Suggests" et al).
In this case, I think disjunctive dependencies (default | virtual), as
Matthew Garrett pointed out, are the right solution, not soft dependencies
(though those would also be nice).
Kevin Kofler
Functionally speaking, what is the difference between a soft
dependency
and a disjunctive dependency? How can you satisfy a soft dependency if
you don't know what virtual dependency it is being used to provide?
-Matyas
11 a.m.
On Mon, Sep 19, 2011 at 10:51:26AM -0500, Matyas Selmeci wrote:
Kevin Kofler wrote on Mon, Sep 19, 2011 at 01:02:26PM +0200:
> Michael Schroeder wrote:
> > Sounds like you want weak dependencies (i.e. "Suggests" et al).
>
> In this case, I think disjunctive dependencies (default | virtual), as
> Matthew Garrett pointed out, are the right solution, not soft dependencies
> (though those would also be nice).
>
> Kevin Kofler
Functionally speaking, what is the difference between a soft dependency
and a disjunctive dependency? How can you satisfy a soft dependency if
you don't know what virtual dependency it is being used to provide?
If we have:
Requires: phonon-backend
Suggests: phonon-backend-gstreamer
What would you expect the outcome to be on a system that has
phonon-backend-xine? I'd have thought that phonon-backend-gstreamer
would get installed, even if you can later remove it. That's not the
desired outcome.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
11:05 a.m.
Matthew Garrett wrote on Mon, Sep 19, 2011 at 05:00:28PM +0100:
On Mon, Sep 19, 2011 at 10:51:26AM -0500, Matyas Selmeci wrote:
> Kevin Kofler wrote on Mon, Sep 19, 2011 at 01:02:26PM +0200:
> > Michael Schroeder wrote:
> > > Sounds like you want weak dependencies (i.e. "Suggests" et al).
> >
> > In this case, I think disjunctive dependencies (default | virtual), as
> > Matthew Garrett pointed out, are the right solution, not soft dependencies
> > (though those would also be nice).
> >
> > Kevin Kofler
> Functionally speaking, what is the difference between a soft dependency
> and a disjunctive dependency? How can you satisfy a soft dependency if
> you don't know what virtual dependency it is being used to provide?
If we have:
Requires: phonon-backend
Suggests: phonon-backend-gstreamer
What would you expect the outcome to be on a system that has
phonon-backend-xine? I'd have thought that phonon-backend-gstreamer
would get installed, even if you can later remove it. That's not the
desired outcome.
I see. So 'Suggests' means it gets automatically installed (unless it
explicitly conflicts with something already install I presume?), but
can be removed without breaking the package it was brought in for
(unless no other package provides the phonon-backend dependency).
Do I have that right?
-Matyas
11:08 a.m.
On Mon, Sep 19, 2011 at 11:05:47AM -0500, Matyas Selmeci wrote:
Matthew Garrett wrote on Mon, Sep 19, 2011 at 05:00:28PM +0100:
> On Mon, Sep 19, 2011 at 10:51:26AM -0500, Matyas Selmeci wrote:
> > Kevin Kofler wrote on Mon, Sep 19, 2011 at 01:02:26PM +0200:
> > > Michael Schroeder wrote:
> > > > Sounds like you want weak dependencies (i.e. "Suggests" et
al).
> > >
> > > In this case, I think disjunctive dependencies (default | virtual), as
> > > Matthew Garrett pointed out, are the right solution, not soft dependencies
> > > (though those would also be nice).
> > >
> > > Kevin Kofler
> > Functionally speaking, what is the difference between a soft dependency
> > and a disjunctive dependency? How can you satisfy a soft dependency if
> > you don't know what virtual dependency it is being used to provide?
>
> If we have:
>
> Requires: phonon-backend
> Suggests: phonon-backend-gstreamer
>
> What would you expect the outcome to be on a system that has
> phonon-backend-xine? I'd have thought that phonon-backend-gstreamer
> would get installed, even if you can later remove it. That's not the
> desired outcome.
I see. So 'Suggests' means it gets automatically installed (unless it
explicitly conflicts with something already install I presume?), but
can be removed without breaking the package it was brought in for
(unless no other package provides the phonon-backend dependency).
Do I have that right?
In Debian, 'Suggests', 'Recommends' etc have very specific meanings.
See in particular section 7.2 here:
http://www.debian.org/doc/debian-policy/ch-relationships.html
RPM of course doesn't have anything except hard requirements.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
11:25 a.m.
On Mon, Sep 19, 2011 at 11:05:47AM -0500, Matyas Selmeci wrote:
I see. So 'Suggests' means it gets automatically installed
(unless it
explicitly conflicts with something already install I presume?), but
can be removed without breaking the package it was brought in for
(unless no other package provides the phonon-backend dependency).
Do I have that right?
Actually 'Recommends' should be used when you want automatic
installation. Suggests is more a hint for the user.
Depsolvers often also use it to break ambiguities, so when
multiple packages provide some dependency, the suggested one
is chosen.
Cheers,
Michael.
--
Michael Schroeder mls(a)suse.de
SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
11:51 a.m.
----- Original Message -----
On Mon, Sep 19, 2011 at 10:51:26AM -0500, Matyas Selmeci wrote:
> Kevin Kofler wrote on Mon, Sep 19, 2011 at 01:02:26PM +0200:
> > Michael Schroeder wrote:
> > > Sounds like you want weak dependencies (i.e. "Suggests" et al).
> >
> > In this case, I think disjunctive dependencies (default |
> > virtual), as
> > Matthew Garrett pointed out, are the right solution, not soft
> > dependencies
> > (though those would also be nice).
> >
> > Kevin Kofler
> Functionally speaking, what is the difference between a soft
> dependency
> and a disjunctive dependency? How can you satisfy a soft dependency
> if
> you don't know what virtual dependency it is being used to provide?
If we have:
Requires: phonon-backend
Suggests: phonon-backend-gstreamer
What would you expect the outcome to be on a system that has
phonon-backend-xine? I'd have thought that phonon-backend-gstreamer
would get installed, even if you can later remove it. That's not the
desired outcome.
I wouldn't have thought that. I would have thought that if the Requires was already
satisfied by phonon-backend-xine, that processing would stop there. You have no need for
suggests or recommends either one when the dependency is already satisfied IMO. But, I
didn't write any spec around that, so it may be implemented differently in the real
(deb) world.
12:08 p.m.
On Mon, Sep 19, 2011 at 12:51:29PM -0400, Doug Ledford wrote:
I wouldn't have thought that. I would have thought that if the
Requires was already satisfied by phonon-backend-xine, that processing
would stop there. You have no need for suggests or recommends either
one when the dependency is already satisfied IMO. But, I didn't write
any spec around that, so it may be implemented differently in the real
(deb) world.
It is.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
1:50 p.m.
On Fri, 2011-09-16 at 19:42 +0100, Richard Hughes wrote:
On 16 September 2011 18:43, seth vidal
<skvidal(a)fedoraproject.org> wrote:
> having different tools is not acceptable. Especially when one of them is
> not even remotely covering the use cases of our actual users.
Installing 205 new i686 packages when updating the system is not acceptable.
I agree with that. The cases where that occurs are all tied up in
insufficiently specified requirements.
> I think I'm going to suggest to fesco that all non-yum
depsolvers be
> removed from the distribution. It just creates more work than it does
> value.
Ha! That's really funny, and it's just made my evening. While you're
asking fesco, can you also ask them to remove KDE and XFCE as well
please.
I've made the proposal for non-yum-based package managers to be removed
from fedora.
Your attitude is quite unfortunate. I'd hope you'd want to work with
others to make fedora better but you don't. There's a packaging team you
should work with and for if you intend to continue working on package
managers.
-sv
8:36 p.m.
seth vidal wrote:
On Fri, 2011-09-16 at 19:42 +0100, Richard Hughes wrote:
> Installing 205 new i686 packages when updating the system is not
> acceptable.
I agree with that. The cases where that occurs are all tied up in
insufficiently specified requirements.
So you came up with this really complex heuristic in a vain attempt to
always do the right thing without requiring changes to the packages, and now
it does a completely wrong thing which would be straightforward to avoid,
and suddenly it's the packages that need fixing? Huh?
I've made the proposal for non-yum-based package managers to be
removed
from fedora.
WTF?!
If we were to keep only one depsolver, once zif is stable, which one would
we want to keep:
* the tool written in a slow interpreted language, which cannot even be
loaded into the process of the backend for our default package management
GUI, requiring complex hacks to be spawned out of process and to bridge the
language gap, or
* the tool written in the same compiled language as our default package
management GUI (and its backend daemon) and by the same primary developer,
which can be loaded simply as a shared library?
I know you want your own code to be used, but let's be honest…
Yum's reliance on Python is a major design flaw causing several problems for
Fedora:
* depsolving slowness and memory use (e.g. I'm sure Python is to blame for a
significant part of Anaconda's skyrocketing memory requirements; PackageKit
update checks through yum are also a huge CPU and memory hog etc.),
* making Python (a huge interpreter) part of the critical path,
* upgrade issues like the infamous "yum from F10 updates has a higher EVR
than yum from F11 GA, but is built against the old Python and won't run on
F11" issue which was a PITA to recover from,
* inability to be loaded as a shared library into compiled programs like the
PackageKit daemon,
* relying on the deprecated Python 2 and slowing down Python 3 adoption.
Kevin Kofler
2:03 a.m.
On 17 September 2011 02:36, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
So you came up with this really complex heuristic in a vain attempt
to
always do the right thing without requiring changes to the packages, and now
it does a completely wrong thing which would be straightforward to avoid,
and suddenly it's the packages that need fixing? Huh?
Sure, I don't understand this either. The whole %{isa} thing is a
crutch. I can't think of a single case where I want a new i386 package
to satisfy a dep on my x86_64 system that's not *explicitly*
specified. If the correct package isn't available, then just skip this
package until the next updates check, and hope the repos are in a more
sane state next time.
Anyway, if anyone wants to know the fesco ticket, it's here:
https://fedorahosted.org/fesco/ticket/669
Richard.
4:58 a.m.
Richard Hughes wrote:
Anyway, if anyone wants to know the fesco ticket, it's here:
https://fedorahosted.org/fesco/ticket/669
Thanks for actually posting the link!
To Seth: What a bunch of nonsense!
This is a more serious proposal:
https://fedoraproject.org/wiki/Features/ZifByDefaultForDesktop
IMHO, Elad's proposal makes a lot of sense and I fully support it.
Kevin Kofler
3:52 p.m.
On Fri, 2011-09-16 at 19:42 +0100, Richard Hughes wrote:
There's really nothing special about a package manager I assure
you.
Assuming, for a moment, that You; Seth and I are all equally
experienced in package management and that while you would "assure"
that, we would ... not.
Given that, I'm curious if you know of any other people who agree with
your assurance ... Panu? Florian? Jindrich? ... Adam (ajax)? Jeremy?
Tim? ... any major contributor to anaconda? ... any major contributor to
apt, dpkg or zypp? Any of the rPath guys?
2:02 p.m.
On Fri, Sep 16, 2011 at 01:43:53PM -0400, seth vidal wrote:
On Fri, 2011-09-16 at 19:31 +0200, Miloslav Trmač wrote:
> On Fri, Sep 16, 2011 at 7:26 PM, Richard Hughes <hughsient(a)gmail.com> wrote:
> > On 16 September 2011 17:36, seth vidal <skvidal(a)fedoraproject.org>
wrote:
> >> Here is how yum does comparison between multiple package providing the
> >> same thing:
> >> http://yum.baseurl.org/wiki/CompareProviders
> <snip>
> > In Zif, I'm doing something like:
> ...
>
> I don't particularly care how the best provider is selected, but
> having different tools use different rules is not acceptable.
having different tools is not acceptable. Especially when one of them is
not even remotely covering the use cases of our actual users.
I think I'm going to suggest to fesco that all non-yum depsolvers be
removed from the distribution. It just creates more work than it does
value.
If someone wants to ship a depsolver in their own repo on fedorapeople,
that's fine but providing it in the distro is just a mistake.
Is Zif a SAT solver?
We could really use a SAT solver to replace the current yum depsolver.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
2:08 p.m.
On Fri, 2011-09-16 at 20:02 +0100, Richard W.M. Jones wrote:
Is Zif a SAT solver?
We could really use a SAT solver to replace the current yum depsolver.
no, it is not a satsolver.
1. a satsolver is not the panacea that is purported to be - you end up
with some funny resolutions that do satisfy the requirements but not
sensibly.
2. a satsolver is going to require changing around how we truck the
repodata around a good bit.
3. if a satsolver is implemented it needs to be done so that anaconda
can use it too. Not to mention mock, the compose tools, masher, etc.
All of our tools go through yum - if we want to change things - doing it
in yum makes for a lot fewer code changes to everything else - not to
mention the code we don't control which uses it.
-sv
2:32 p.m.
On 16 September 2011 20:02, Richard W.M. Jones <rjones(a)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.
We could really use a SAT solver to replace the current yum
depsolver.
SAT is pretty awesome, and there are some pretty clever guys who have
got it to work really well with zypp. I can't say I understand all the
subtle nuances, but it's clearly better than an iterative depsolver
with random rules to steer things in the right direction. Plus, once
you've populated the .sat files, it's really fast.
Richard.
4:22 p.m.
On 09/17/2011 01:02 AM, Richard Hughes wrote:
SAT is pretty awesome, and there are some pretty clever guys who
have
got it to work really well with zypp. I can't say I understand all the
subtle nuances, but it's clearly better than an iterative depsolver
with random rules to steer things in the right direction. Plus, once
you've populated the .sat files, it's really fast.
If you have decided you are going to do something different with Zif
anyway, you might as well as work with the zypper team and see whether
you can make something out of it. So much of what we do in Fedora is
built around yum though and I don't know what you have planned but go
through years of subtle bugs in a new dep resolver stops being funny
quickly.
Rahul
8:38 p.m.
Rahul Sundaram wrote:
If you have decided you are going to do something different with Zif
anyway, you might as well as work with the zypper team and see whether
you can make something out of it. So much of what we do in Fedora is
built around yum though and I don't know what you have planned but go
through years of subtle bugs in a new dep resolver stops being funny
quickly.
Unfortunately, zypp has some design flaws of its own. In particular, it
spawns the rpm command line as an external process for some operations
instead of using librpm as it's supposed to (yet other operations use the
library).
Kevin Kofler
10:07 p.m.
On 09/17/2011 07:08 AM, Kevin Kofler wrote:
Ra
Unfortunately, zypp has some design flaws of its own. In particular, it
spawns the rpm command line as an external process for some operations
instead of using librpm as it's supposed to (yet other operations use the
library).
Nothing that can't be fixed. If nothing is perfect, then often you work
from the one that closest to the solution you want.
Rahul
8:14 a.m.
On Sat, Sep 17, 2011 at 03:38:55AM +0200, Kevin Kofler wrote:
Rahul Sundaram wrote:
> If you have decided you are going to do something different with Zif
> anyway, you might as well as work with the zypper team and see whether
> you can make something out of it. So much of what we do in Fedora is
> built around yum though and I don't know what you have planned but go
> through years of subtle bugs in a new dep resolver stops being funny
> quickly.
Unfortunately, zypp has some design flaws of its own. In particular, it
spawns the rpm command line as an external process for some operations
instead of using librpm as it's supposed to (yet other operations use the
library).
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.)
Url: https://github.com/opensuse/libsolv
Cheers,
Michael.
--
Michael Schroeder mls(a)suse.de
SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
8:49 a.m.
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
12:40 p.m.
On 09/17/2011 01:02 AM, Richard Hughes wrote:
On 16 September 2011 20:02, Richard W.M. Jones
<rjones(a)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 Schröder 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
1:22 p.m.
On 09/18/2011 08:40 PM, Rahul Sundaram wrote:
On 09/17/2011 01:02 AM, Richard Hughes wrote:
> On 16 September 2011 20:02, Richard W.M. Jones<rjones(a)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 Schröder 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.
I've a feeling people are going to interpret the "merge a depsolver into
rpm" thing in various different ways, lets clarify this a bit:
I'm talking about means of having all the rpm-related tools use the same
abstract dependency resolution algorithm though an API. Whether that is
/in/ rpm, or something that rpm itself /uses/ (and possibly further
exports via its own API) is not terribly relevant to that goal.
What I'm NOT talking about is turning rpm into
yum/zif/apt/smart/zypp/urpmi kind of tool which deal with concrete
repositories, downloading information from them etc.
- Panu -
2:53 p.m.
On 18 September 2011 19:22, Panu Matilainen <pmatilai(a)laiskiainen.org> wrote:
I'm talking about means of having all the rpm-related tools use
the same
abstract dependency resolution algorithm though an API. Whether that is
/in/ rpm, or something that rpm itself /uses/ (and possibly further
exports via its own API) is not terribly relevant to that goal.
If rpm exposed a depsolve API, I would switch to it in a heartbeat. If
it's C, it's good for me. If it's based around libsolv, then even
better.
Richard.
12:49 p.m.
On Fri, 2011-09-16 at 18:26 +0100, Richard Hughes wrote:
On 16 September 2011 17:36, seth vidal
<skvidal(a)fedoraproject.org> wrote:
> Here is how yum does comparison between multiple package providing the
> same thing:
> http://yum.baseurl.org/wiki/CompareProviders
I don't think that works for all cases; surely "grid-certificates = 2"
wins over "grid-certificates = 1" in all cases? It's certainly better
than relying on the length of the package name or alphabetical
ordering...
Which, if you read, yum doesn't do exclusively.
Here's what yum does.
0. each pkg starts out with a score of 0.
1. if any of the providers is a newer version of something we have
installed then increase their score by 5
2. if any of the providers are not the newest version of themselves then
decrease their score by 1024.
3. if any of the providers are obsoleted by another provider, decrease
that provider by 1024.
4. check the arch distance between the requiring pkg and each of the
providers. The pkg with the smallest arch distance gets a 5 added to
their score. Do the same check but comparing the pkg arch distance to
the system arch, not the requiring pkg arch
5. compare the sourcerpm on each provider to the requiring pkg's source
rpm. If they share a sourcerpm add 20 to the score
6. check the base pkg for each subpkg. If the base pkg is installed on
the system add 5 to the provider's score.
7. check the prefix of the pkg to the requiring pkg prefix (perl-foo and
perl-lib) for each common character in the prefix add 2 points to the
provider's score.
8. if, at this point, we have pkgs with an equal score - look at the
deplist (one layer deep) and see what they would pull in that is NOT
already installed. Add 1 to the score of the pkg with the least new deps
to be pulled in.
9. if all else fails and we STILL have two pkgs with the same score -
take the leaders from the list and compare their name length. We add
1,000 and then subtract the length of the number of character's in the
pkgs name from its score (the addition of 1000 is to ensure that one of
the leaders will be picked).
10. return the list of providers, sorted best to worst.
11. if the packages are the same length, then the packages are compared
as shown in "yum list". The one lower in the list will win.
In Zif, I'm doing something like:
* Filter by best arch
* Filter by depend version
* Filter by native arch
* Filter by smallest name
* Filter by newest
So you fail to take shortest number of deps and you're going to
generally fail for a any number of pkgs which really need a
closely-related sibling package but something else outside of their srpm
also provides what they need.
That happens a lot in the kde/gnome world and with many of the languages
with a large number of modules. (python, perl, etc)
Yum's depsolving and provider comparison is significantly more mature
and works in actual uses not just theoretically.
That you've implemented a depsolver for use with PK that does not match
yum nor anaconda is pretty bad. You've chosen intentional
incompatibility. That's neither helpful nor really embodying the goals I
like to think of in fedora.
non-native architecture packages onto their system for an update and
want to follow the latest provide version (even if that means
installing additional deps). The current logic where yum wants to
install a hundred i686 packages on my x86_64 box when the repos get a
bit screwy doesn't seem to work very well in my opinion.
There are still a largish number of packages out there that have things
like:
Requires: foo
where they really want:
Requires: foo(64bit)
Which causes the other path you're describing.
It's sad that you've chosen to implement something else entirely on your
own rather than working with the growing number of people working on
yum.
-sv
3:53 p.m.
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.
--
Fedora release 16 (Verne) - Linux 3.1.0-0.rc6.git0.0.fc16.x86_64
loadavg: 0.06 0.07 0.11
9:23 a.m.
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 -
9:58 a.m.
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
1:52 p.m.
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 -
4:11 p.m.
On 09/16/2011 08:49 PM, seth vidal wrote:
On Fri, 2011-09-16 at 18:26 +0100, Richard Hughes wrote:
> The current logic where yum wants to install a hundred i686
> packages on my x86_64 box when the repos get a bit screwy doesn't
> seem to work very well in my opinion.
There are still a largish number of packages out there that have things
like:
Requires: foo
where they really want:
Requires: foo(64bit)
Which causes the other path you're describing.
I'd much prefer if yum depsolver could handle this instead of making
everyone use kludges like %{_isa} in the spec files. It's perfectly fine
if rpm accepts the "wrong" arch. Yum, however, should be tailored for
the way we are doing multilib in Fedora and just do the right thing.
I would be hard pressed to find any real life case where picking the 32
bit package instead of the 64 bit one would give any advantage, provided
that both are coming from Fedora repos.
Seth, have you considered making arch distance give more than the 5
points it currently has in the yum depsolver scoring logic?
--
Kalev
7:52 p.m.
seth vidal wrote:
That you've implemented a depsolver for use with PK that does not
match
yum nor anaconda is pretty bad. You've chosen intentional
incompatibility. That's neither helpful nor really embodying the goals I
like to think of in fedora.
It's quite funny that you're accusing Richard of being incompatible with yum
when the incompatibilities that matter most to our users have been required
by yum developers, in particular:
* no writing to the yum database by default,
* no parsing yum.conf by default.
Kevin Kofler
1:21 a.m.
On Sat, Sep 17, 2011 at 02:52:58AM +0200, Kevin Kofler wrote:
seth vidal wrote:
> That you've implemented a depsolver for use with PK that does not match
> yum nor anaconda is pretty bad. You've chosen intentional
> incompatibility. That's neither helpful nor really embodying the goals I
> like to think of in fedora.
It's quite funny that you're accusing Richard of being incompatible with yum
when the incompatibilities that matter most to our users have been required
by yum developers, in particular:
* no writing to the yum database by default,
* no parsing yum.conf by default.
... and no way to access yum information from anything other than
Python, which makes it harder to use more professional programming
languages and yum data together. I had to write a whole bit of code
that spawned a Python process to get some dependency data, write it to
a file, and parse that back in to the real program.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
2:08 a.m.
On 17 September 2011 07:21, Richard W.M. Jones <rjones(a)redhat.com> wrote:
... and no way to access yum information from anything other than
Python, which makes it harder to use more professional programming
languages and yum data together. I had to write a whole bit of code
that spawned a Python process to get some dependency data, write it to
a file, and parse that back in to the real program.
Out of interest, would Zif allow you to do this? There are some
example programs here:
https://github.com/hughsie/zif/tree/master/examples or some developer
docs here: http://people.freedesktop.org/~hughsient/zif/docs/
Richard.
4:38 a.m.
On Sat, Sep 17, 2011 at 08:08:24AM +0100, Richard Hughes wrote:
On 17 September 2011 07:21, Richard W.M. Jones
<rjones(a)redhat.com> wrote:
> ... and no way to access yum information from anything other than
> Python, which makes it harder to use more professional programming
> languages and yum data together. I had to write a whole bit of code
> that spawned a Python process to get some dependency data, write it to
> a file, and parse that back in to the real program.
Out of interest, would Zif allow you to do this? There are some
example programs here:
https://github.com/hughsie/zif/tree/master/examples or some developer
docs here: http://people.freedesktop.org/~hughsient/zif/docs/
Yeah, it looks possible.
The very fact that you're exposing a C API and a library is a
promising start, even if it didn't yet do specifically what I needed.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
4:54 a.m.
On 17 September 2011 10:38, Richard W.M. Jones <rjones(a)redhat.com> wrote:
Yeah, it looks possible.
The very fact that you're exposing a C API and a library is a
promising start, even if it didn't yet do specifically what I needed.
Would it be easier if I provided a GIR file so you can just use
gobject-introspection?
Anyway, let me know if zif falls short or looks odd as an API and I'll
see what I can do.
Richard.
5:05 a.m.
On Sat, Sep 17, 2011 at 10:54:35AM +0100, Richard Hughes wrote:
On 17 September 2011 10:38, Richard W.M. Jones
<rjones(a)redhat.com> wrote:
> Yeah, it looks possible.
> The very fact that you're exposing a C API and a library is a
> promising start, even if it didn't yet do specifically what I needed.
Would it be easier if I provided a GIR file so you can just use
gobject-introspection?
I don't mind as long as it's callable from other languages (either
using generated bindings like GIR or using hand written bindings).
I would just caution that I found GIR was not expressive enough to
implement libguestfs bindings. Specifically it lacked support for
optional arguments and structs (unless encapsulated as an object). I
don't know whether or not that would affect zif.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
5:43 a.m.
On 17 September 2011 11:05, Richard W.M. Jones <rjones(a)redhat.com> wrote:
I don't mind as long as it's callable from other languages
(either
using generated bindings like GIR or using hand written bindings).
I've just pushed:
commit 4132eb5a40e1a6a85358e96f7adfd3cf56e8ef3f
Author: Richard Hughes <richard(a)hughsie.com>
Date: Sat Sep 17 11:34:34 2011 +0100
Enable GObject introspection support
I would just caution that I found GIR was not expressive enough to
implement libguestfs bindings. Specifically it lacked support for
optional arguments and structs (unless encapsulated as an object). I
don't know whether or not that would affect zif.
Ohh, 99.9% of Zif is using GObjects and GTypes, so I don't think that
will be a problem here.
Richard.
4:40 a.m.
I meant to add this link to the current Python-subprocess code:
http://git.annexia.org/?p=febootstrap.git;a=blob;f=src/febootstrap_yum_rp...
Note the extra backslashes and double %%'s are because the Python code
is contained in a printf-like string.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
5:59 a.m.
On 09/17/2011 06:22 AM, Kevin Kofler wrote:
It's quite funny that you're accusing Richard of being
incompatible with yum
when the incompatibilities that matter most to our users have been required
by yum developers, in particular:
* no writing to the yum database by default,
* no parsing yum.conf by default.
Adding a conflicts to yum against zif was a inappropriate use of
conflicts and must have been resolved in a better way. The animosity
between people working on competing solutions is leading to a proposal
which really wouldn't fly. Having said that, I think zif needs to be
command line compatible and support delta RPMs by default for it to be
the default backend for the desktop and I really don't think desktop
environments should have a different dep resolver from the rest of
Fedora. I don't know if I want to use zif yet but Richard Hughes
should aim for a comprehensive solution instead of just addressing the
PackageKit problem in a narrow way because I think the problem
PackageKit is facing is also true for other tools. Libguestfs has
already come out as an example.
Rahul
6:20 a.m.
Rahul Sundaram wrote:
Adding a conflicts to yum against zif was a inappropriate use of
conflicts and must have been resolved in a better way. The animosity
between people working on competing solutions is leading to a proposal
which really wouldn't fly. Having said that, I think zif needs to be
command line compatible and support delta RPMs by default for it to be
the default backend for the desktop and I really don't think desktop
Delta RPM support is listed as one of the 3 things which don't work yet, so
I'm pretty sure it's planned.
(That said, there definitely needs to be a way to disable it, and maybe it
should even be disabled by default. I personally always uninstall yum-
presto. For me, it's much faster to just download packages than to rebuild
them from deltas. Only users on really slow connections benefit from it.)
environments should have a different dep resolver from the rest of
Fedora.
While I think Fedora would benefit from using zif throughout (mainly because
it's in a compiled language, not in Python), I don't agree that this should
be a requirement for using zif in PackageKit. PackageKit should use what is
best suited for its needs, which yum clearly isn't.
I don't know if I want to use zif yet but Richard Hughes
should aim for a comprehensive solution instead of just addressing the
PackageKit problem in a narrow way because I think the problem
PackageKit is facing is also true for other tools. Libguestfs has
already come out as an example.
Richard Hughes is being receptive to other uses of zif than PackageKit, see
the subthread with Richard W.M. Jones.
Kevin Kofler
6:27 a.m.
On 09/17/2011 04:50 PM, Kevin Kofler wrote:
While I think Fedora would benefit from using zif throughout (mainly
because
it's in a compiled language, not in Python), I don't agree that this should
be a requirement for using zif in PackageKit. PackageKit should use what is
best suited for its needs, which yum clearly isn't.
You misunderstood me. I don't think it is requirement but I just think
a broader plan needs to be in place and deal with the politics of it
head on. I have the same opinion on using the software centre UI in
Fedora for that matter. Fork if necessary and get the job done.
Rahul
12:51 a.m.
On Sat, 2011-09-17 at 13:20 +0200, Kevin Kofler wrote:
(That said, there definitely needs to be a way to disable it, and
maybe it
should even be disabled by default. I personally always uninstall yum-
presto. For me, it's much faster to just download packages than to rebuild
them from deltas. Only users on really slow connections benefit from it.)
My desktop can rebuild deltas at ~3MB/sec. So even my really fast
internet connection is slower than delta rebuild.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
5:54 a.m.
On 10/05/2011 01:51 AM, Adam Williamson wrote:
On Sat, 2011-09-17 at 13:20 +0200, Kevin Kofler wrote:
> (That said, there definitely needs to be a way to disable it, and maybe it
> should even be disabled by default. I personally always uninstall yum-
> presto. For me, it's much faster to just download packages than to rebuild
> them from deltas. Only users on really slow connections benefit from it.)
My desktop can rebuild deltas at ~3MB/sec. So even my really fast
internet connection is slower than delta rebuild.
This is a meaningless comment to
other people unless you provide
information on what the specs of your desktop are or the speed of your internet
connection.
--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark(a)netwolves.com
http://www.netwolves.com
3:44 p.m.
On Wed, 2011-10-05 at 06:54 -0400, Steve Clark wrote:
On 10/05/2011 01:51 AM, Adam Williamson wrote:
> On Sat, 2011-09-17 at 13:20 +0200, Kevin Kofler wrote:
>
> > (That said, there definitely needs to be a way to disable it, and maybe it
> > should even be disabled by default. I personally always uninstall yum-
> > presto. For me, it's much faster to just download packages than to rebuild
> > them from deltas. Only users on really slow connections benefit from it.)
> My desktop can rebuild deltas at ~3MB/sec. So even my really fast
> internet connection is slower than delta rebuild.
This is a meaningless comment to other people unless you provide
information on what the specs of your desktop are or the speed of your
internet connection.
No, it isn't, because Kevin rashly made an absolutely categorical
statement that 'Only users on really slow connections' benefit from it.
You don't need to know what speed my personal internet connection is to
know that 3MB/sec (that's mega*bytes*, remember, internet connections
are specified in mega*bits* - 3MB/sec is 24Mb/sec) is a hell of a lot
faster than many internet connections can manage, handily contradicting
his assertion. Yes, my desktop is very fast, but so what? Kevin's
statement wasn't conditional upon system specs.
(My connection is actually specced at 25Mb/sec, but it rarely manages
that to a Fedora mirror; I usually get about 8Mb/sec for package
downloads).
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
2:35 p.m.
On Tue, Oct 04, 2011 at 10:51:43PM -0700, Adam Williamson wrote:
> (That said, there definitely needs to be a way to disable it,
and maybe it
> should even be disabled by default. I personally always uninstall yum-
> presto. For me, it's much faster to just download packages than to rebuild
> them from deltas. Only users on really slow connections benefit from it.)
My desktop can rebuild deltas at ~3MB/sec. So even my really fast
internet connection is slower than delta rebuild.
Your internet connection is clearly not fast enough. :)
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
2:48 p.m.
On Thu, 2011-10-06 at 15:35 -0400, Matthew Miller wrote:
On Tue, Oct 04, 2011 at 10:51:43PM -0700, Adam Williamson wrote:
> > (That said, there definitely needs to be a way to disable it, and maybe it
> > should even be disabled by default. I personally always uninstall yum-
> > presto. For me, it's much faster to just download packages than to rebuild
> > them from deltas. Only users on really slow connections benefit from it.)
> My desktop can rebuild deltas at ~3MB/sec. So even my really
fast
> internet connection is slower than delta rebuild.
Your internet connection is clearly not fast enough. :)
Not all of us get university pipes all our lives, Matt ;)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
2:50 p.m.
On Wed, Oct 5, 2011 at 7:51 AM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Sat, 2011-09-17 at 13:20 +0200, Kevin Kofler wrote:
> (That said, there definitely needs to be a way to disable it, and maybe it
> should even be disabled by default. I personally always uninstall yum-
> presto. For me, it's much faster to just download packages than to rebuild
> them from deltas. Only users on really slow connections benefit from it.)
My desktop can rebuild deltas at ~3MB/sec. So even my really fast
internet connection is slower than delta rebuild.
It can be made faster by
1) doing mutliple rebuilds in parallel
2) create uncompressed rpms (there is no point in compressing them
just to uncompress them shortly afterwards).
But 2) is kind of tricky with signing.
6:34 a.m.
On 17 September 2011 11:59, Rahul Sundaram <metherid(a)gmail.com> wrote:
I think zif needs to be command line compatible and support delta
RPMs
The former should work pretty well. If I've missed any obvious aliases
yell and I'll add them. The latter is 80% implemented, but I don't use
delta-rpms myself and it was left for somebody else to do. It would be
a nice little project for someone wanting to get to know Zif
internally. I can write up exactly what needs to be done if you mail
me offlist.
If delta-rpms support is a must-have then I can probably finish it in
a day or so. No biggie. :-)
...I think the problem PackageKit is facing is also true for other
tools.
I agree. I've just merged the GIR generation into master, so hopefully
it would be possible to do things like use Zif from PHP and Javascript
in the future.
Richard.
7:56 a.m.
Richard Hughes wrote:
On 17 September 2011 11:59, Rahul Sundaram <metherid(a)gmail.com>
wrote:
> ...I think the problem PackageKit is facing is also true for other tools.
I agree. I've just merged the GIR generation into master, so hopefully
it would be possible to do things like use Zif from PHP and Javascript
in the future.
And Python too, I suppose?
/me starts cursorily looking in the general direction of Anaconda. ;-)
Kevin Kofler
4586
days inactive
4606
days old
91 comments
22 participants
participants (22)
-
Adam Williamson -
Björn Persson -
Doug Ledford -
drago01 -
James Antill -
Jef Spaleta -
Kalev Lember -
Kevin Kofler -
Matthew Garrett -
Matthew Miller -
Michael Schroeder -
Michael Schwendt -
Miloslav Trmač -
Mátyás Selmeci -
Nils Philippsen -
Panu Matilainen -
Rahul Sundaram -
Richard Hughes -
Richard W.M. Jones -
Seth Vidal -
Steve Clark -
Tim Lauridsen