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
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,
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, swingingegos.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora
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
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
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
On Mon, 2011-09-19 at 18:11 +0200, drago01 wrote:
On Mon, Sep 19, 2011 at 5:46 PM, tim.laurid...@gmail.com
tim.laurid...@gmail.com wrote:
On Mon, Sep 19, 2011 at 1:00 PM, Kevin Kofler kevin.kof...@chello.at
wrote:
Matthew Garrett wrote:
Debian policy is that any virtual dependencies
On 19 September 2011 01:46, Kevin Kofler kevin.kof...@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
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
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.
Kevin Kofler
--
devel mailing
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
--
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
On Mon, Sep 19, 2011 at 1:00 PM, Kevin Kofler kevin.kof...@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,
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
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 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
On Mon, Sep 19, 2011 at 5:46 PM, tim.laurid...@gmail.com
tim.laurid...@gmail.com wrote:
On Mon, Sep 19, 2011 at 1:00 PM, Kevin Kofler kevin.kof...@chello.at wrote:
Matthew Garrett wrote:
Debian policy is that any virtual dependencies must also have an
explicit dependency. In your case it would
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
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:
On Sun, Sep 18, 2011 at 2:44 PM, Kevin Kofler kevin.kof...@chello.atwrote:
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
- 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
tim.laurid...@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
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
On 19 September 2011 17:41, Jef Spaleta jspal...@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
On Mon, Sep 19, 2011 at 9:33 AM, Richard Hughes hughsi...@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 lng time and it's probably just a
trivial bug. Thanks.
Filed : Bug
On 17 September 2011 23:06, Jef Spaleta jspal...@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
On 09/17/2011 01:02 AM, Richard Hughes wrote:
On 16 September 2011 20:02, Richard W.M. Jones rjo...@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
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. Jonesrjo...@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
On 18 September 2011 19:22, Panu Matilainen pmati...@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
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:
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
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:
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
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
On 17 September 2011 02:36, Kevin Kofler kevin.kof...@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,
On Sat, Sep 17, 2011 at 08:08:24AM +0100, Richard Hughes wrote:
On 17 September 2011 07:21, Richard W.M. Jones rjo...@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
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_rpm.ml;h=028492a0d3c894e7cb2c85b446f6bff272217147;hb=HEAD#l35
Note the extra backslashes and double %%'s are because the Python code
is contained in a
On 17 September 2011 10:38, Richard W.M. Jones rjo...@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
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:
On Sat, Sep 17, 2011 at 10:54:35AM +0100, Richard Hughes wrote:
On 17 September 2011 10:38, Richard W.M. Jones rjo...@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
On 17 September 2011 11:05, Richard W.M. Jones rjo...@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
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
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
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
On 17 September 2011 11:59, Rahul Sundaram methe...@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
Richard Hughes wrote:
On 17 September 2011 11:59, Rahul Sundaram methe...@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
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
On 17 September 2011 13:56, Kevin Kofler kevin.kof...@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
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
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
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
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
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
On Fri, Sep 16, 2011 at 11:58 AM, Richard Hughes hughsi...@gmail.comwrote:
On 16 September 2011 20:46, Jef Spaleta jspal...@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
On Sat, Sep 17, 2011 at 12:51 PM, Jef Spaleta jspal...@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.
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
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
On Fri, 2011-09-16 at 18:26 +0100, Richard Hughes wrote:
On 16 September 2011 17:36, seth vidal skvi...@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
On Fri, 2011-09-16 at 19:31 +0200, Miloslav Trmač wrote:
On Fri, Sep 16, 2011 at 7:26 PM, Richard Hughes hughsi...@gmail.com wrote:
On 16 September 2011 17:36, seth vidal skvi...@fedoraproject.org wrote:
Here is how yum does comparison between multiple package providing the
same thing:
On 16 September 2011 18:43, seth vidal skvi...@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
On Fri, Sep 16, 2011 at 8:42 PM, Richard Hughes hughsi...@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
2011/9/16 Miloslav Trmač m...@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
On Fri, 2011-09-16 at 19:42 +0100, Richard Hughes wrote:
On 16 September 2011 18:43, seth vidal skvi...@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
On Fri, 2011-09-16 at 19:48 +0100, Richard Hughes wrote:
2011/9/16 Miloslav Trmač m...@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
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 hughsi...@gmail.com wrote:
On 16 September 2011 17:36, seth vidal skvi...@fedoraproject.org wrote:
Here is how yum does
On Fri, Sep 16, 2011 at 10:48 AM, Richard Hughes hughsi...@gmail.comwrote:
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?
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
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
On Fri, Sep 16, 2011 at 11:10 AM, seth vidal skvi...@fedoraproject.orgwrote:
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
On 16 September 2011 20:07, Jef Spaleta jspal...@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:
On Fri, Sep 16, 2011 at 11:22 AM, Richard Hughes hughsi...@gmail.comwrote:
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
On 16 September 2011 20:02, Richard W.M. Jones rjo...@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
On 16 September 2011 20:32, Jef Spaleta jspal...@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
On Fri, Sep 16, 2011 at 11:35 AM, Richard Hughes hughsi...@gmail.comwrote:
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
On Fri, Sep 16, 2011 at 11:38 AM, Jef Spaleta jspal...@gmail.com wrote:
On Fri, Sep 16, 2011 at 11:35 AM, Richard Hughes hughsi...@gmail.comwrote:
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.
On Fri, Sep 16, 2011 at 11:35 AM, Richard Hughes hughsi...@gmail.comwrote:
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
On 16 September 2011 20:46, Jef Spaleta jspal...@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
On Fri, Sep 16, 2011 at 11:58 AM, Richard Hughes hughsi...@gmail.comwrote:
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
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
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}
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
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
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
Miloslav Trmač wrote:
On Fri, Sep 16, 2011 at 8:42 PM, Richard Hughes hughsi...@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
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
seth vidal wrote:
2. a satsolver is going to require changing around how we truck the
repodata around a good bit.
Yet zypp works fine with the same metadata format we use and using a SAT
solver…
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
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
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
88 matches
Mail list logo
