Re: Zif backport repository for F15 available for testing

[Kevin Kofler]

Kevin Kofler wrote:
> I have put up a repository with an updated zif snapshot for Fedora 15 at:
> http://repos.fedorapeople.org/repos/kkofler/zif-backport/fedora-zif-
backport.repo

There's once again a new snapshot today. (I haven't announced every new 
snapshot in the repository and will NOT announce them every time, just check 
for updates regularly. :-) )

> The repository also includes a rebuild of PackageKit to deal with the
> bumped zif soname. This should only affect PackageKit-zif, but all
> subpackages including the main package are rebuilt, and provided because
> of the strict %{version}-%{release} dependencies.

Since there have been several bug fixes and improvements to PackageKit-zif 
as well, as of NOW, the PackageKit that is provided is no longer a straight 
rebuild, but has pk-backend-zif.c backported from git master (currently 
20110926, but there too, I will NOT make an announcement each time I update 
it). All the other PackageKit files are the same as in the Fedora 15 
package, only the zif backend is backported from master. (I will only 
backport other changes from master if they're needed to build the current 
zif backend. Currently, no such changes are needed.)

Kevin Kofler

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

Re: Zif backport repository for F15 available for testing

[Kevin Kofler]

Jef Spaleta wrote:
> I fully admit that this case is meant to be indicative of a class of
> transactions and not a smoking gun. I was reaching for a simple to
> understand virtual provides scenario, in the same vein as the test cases
> that zif's compile time make check does already.  I believe it is useful
> example for exploring the differences in scoring and the consequences
> thereof.  And considering that Richard has previously stated that he feels
> that yum unnecessarily installs hundreds of packages to fill a dep in some
> cases, I would think he would be interested in making sure zif doesn't end
> up selecting a valid solution that similarly provides an unoptimal outcome
> with regard to downloaded content.

The thing is, doing the right thing there is only possible if you make the 
preferred provider depend on what other packages (which don't provide the 
virtual dependency) the user already has installed, and there's a case for 
NOT doing that: it makes it near impossible for the packager to control what 
should be the default. There are cases like your example where there 
shouldn't be a default, but there are cases where there should, see e.g. my 
Phonon example:
http://lists.fedoraproject.org/pipermail/devel/2011-September/157134.html

Plus, the number of direct dependencies, which yum uses, is not necessarily 
meaningful. Not only doesn't it consider indirect dependencies, but it is 
flawed even for direct ones, e.g. if provider A Requires: huge-monolith (or 
if provider A IS the huge monolith and has no dependencies at all) and 
provider B requires 2 small libraries instead, you might not want the huge 
monolith.

> Though to be honest, i'm much more concerned about what I'm seeing with
> regard to zif behavior on my systems with the adobe or openshift repo
> enabled. I've looked through the repodata for those repositories and I
> just don't see how zif is coming up with the errors it is concerning the
> unsolvable transactions. Correctly handling existing 3rd party repos is
> sort of important. A lot of end users use that adobe plugin repo and if
> enabling it breaks zif in such a way that all transactions fail..thats a
> huge problem.  I could really use some confirmation from someone else to
> make sure what I'm seeing isn't something confined to the particularities
> of my 3 F15 systems I have here.

What you're seeing there is a bug, it's still open, I'm sure it will be 
fixed.

Kevin Kofler

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

Re: Zif backport repository for F15 available for testing

[Rahul Sundaram]

On 09/23/2011 01:39 AM, Doug Ledford wrote:
> - Original Message -
>> I can understand in the case where you have some knowledge of what
>> the
>> various package chains do.
> Such cases do exist.  The libibverbs package requires a libibverbs-driver in 
> order to run.  Which driver you want depends on hardware, and we don't 
> normally install all of them.  A user who bought the hardware in question 
> could probably suss out which package they need to satisfy the dependency if 
> they were asked.

You just made the case for debconf

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

Re: Zif backport repository for F15 available for testing

[Doug Ledford]

- Original Message -
> I can understand in the case where you have some knowledge of what
> the
> various package chains do.

Such cases do exist.  The libibverbs package requires a libibverbs-driver in 
order to run.  Which driver you want depends on hardware, and we don't normally 
install all of them.  A user who bought the hardware in question could probably 
suss out which package they need to satisfy the dependency if they were asked.

-- 
Doug Ledford 
  GPG KeyID: CFBFF194
  http://people.redhat.com/dledford

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

Re: Zif backport repository for F15 available for testing

[Stephen John Smoogen]

On Thu, Sep 22, 2011 at 13:43, Doug Ledford  wrote:
> - Original Message -
>> Wow... just wow.
>>
>> -jef"please hold while koji asks you a series of questions concerning
>> multiple provider cascades to pre-populate the build environment for
>> your rawhide scratch build that you have just requested"spaleta
>
> You can always have a switch to provide the old heuristic if you want.  And 
> that switch can default to on for automated environments like koji.  But 
> since you are asking questions about whether or not zif picks the right 
> package to satisfy a dependency by default, it's fair to ask the question 
> whether or not there *is* a right automatic dependency.
>

I can understand in the case where you have some knowledge of what the
various package chains do. But for a lot of packages I have no clue
and could care less (until I do and then I will be as cranky and
unreasonable as if I had been asked a ton of questions). So in either
way I would say that the package solver is in a un-winnable situation.
They just need to choose one they can live/die with.

-- 
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Let us be kind, one to another, for most of us are fighting a hard
battle." -- Ian MacLaren
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Zif backport repository for F15 available for testing

[Doug Ledford]

- Original Message -
> Wow... just wow.
> 
> -jef"please hold while koji asks you a series of questions concerning
> multiple provider cascades to pre-populate the build environment for
> your rawhide scratch build that you have just requested"spaleta

You can always have a switch to provide the old heuristic if you want.  And 
that switch can default to on for automated environments like koji.  But since 
you are asking questions about whether or not zif picks the right package to 
satisfy a dependency by default, it's fair to ask the question whether or not 
there *is* a right automatic dependency.

-- 
Doug Ledford 
  GPG KeyID: CFBFF194
  http://people.redhat.com/dledford

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

Re: Zif backport repository for F15 available for testing

[Jef Spaleta]

On Thu, Sep 22, 2011 at 10:51 AM, Doug Ledford  wrote:
> - Original Message -
>> I'm
>> just trying to test how well zif handles the multple provider case
>> and understand how it makes the judgment on what is installed.
>
> There's probably a pretty strong argument to be made that if package A 
> requires foo, and packages B, C, and D all provide foo, that the proper 
> answer (whether using zif or yum) would be to ask the user which they would 
> prefer.  Any automated system is going to be prone to being tricked one way 
> or another.

Wow... just wow.

-jef"please hold while koji asks you a series of questions concerning
multiple provider cascades to pre-populate the build environment for
your rawhide scratch build that you have just requested"spaleta
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Zif backport repository for F15 available for testing

[Doug Ledford]

- Original Message -
> I'm
> just trying to test how well zif handles the multple provider case
> and understand how it makes the judgment on what is installed.

There's probably a pretty strong argument to be made that if package A requires 
foo, and packages B, C, and D all provide foo, that the proper answer (whether 
using zif or yum) would be to ask the user which they would prefer.  Any 
automated system is going to be prone to being tricked one way or another.

-- 
Doug Ledford 
  GPG KeyID: CFBFF194
  http://people.redhat.com/dledford

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

Re: Zif backport repository for F15 available for testing

[Jef Spaleta]

On Tue, Sep 20, 2011 at 7:10 PM, Kevin Kofler wrote:

>
> (And besides, your example is about the worst you could pick, since if
> somebody is skilled enough with package management to remove the PackageKit
> frontend, surely he or she knows what to do if zif wants to pick the wrong
> one. ;-) Real end users will ALWAYS have the PackageKit frontend
> installed.)
>
>
I fully admit that this case is meant to be indicative of a class of
transactions and not a smoking gun. I was reaching for a simple to
understand virtual provides scenario, in the same vein as the test cases
that zif's compile time make check does already.  I believe it is useful
example for exploring the differences in scoring and the consequences
thereof.  And considering that Richard has previously stated that he feels
that yum unnecessarily installs hundreds of packages to fill a dep in some
cases, I would think he would be interested in making sure zif doesn't end
up selecting a valid solution that similarly provides an unoptimal outcome
with regard to downloaded content.

Though to be honest, i'm much more concerned about what I'm seeing with
regard to zif behavior on my systems with the adobe or openshift repo
enabled. I've looked through the repodata for those repositories and I just
don't see how zif is coming up with the errors it is concerning the
unsolvable transactions. Correctly handling existing 3rd party repos is sort
of important. A lot of end users use that adobe plugin repo and if enabling
it breaks zif in such a way that all transactions fail..thats a huge
problem.  I could really use some confirmation from someone else to make
sure what I'm seeing isn't something confined to the particularities of my 3
F15 systems I have here.

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

Re: Zif backport repository for F15 available for testing

[Kevin Kofler]

Jef Spaleta wrote:
> you have systems with just KDE and no GNOME installed yes?  zif install
> paprefs
> 
> with kpackagekit not installed does zif do the more optimal thing and pull
> kpackagekit in as a dep to fill  PackageKit-session-service requirement?

I'm not sure why you're asking that. It was already pointed out on more than 
one occasion that zif does NOT decide which provider to pick based on other 
installed packages, by design. But I did the test anyway:


On my notebook, after removing kpackagekit, I get:

Transaction summary:
  Installing:
  1.paprefs-0.9.9-8.fc15.x86_64 (fedora)
  Installing for dependencies:
  1.PackageKit-device-rebind-0.6.17-1.fc15.libzif.so.3.x86_64 (fedora-
zif-backport)
  2.gconfmm26-2.28.2-2.fc15.x86_64 (fedora)
  3.gnome-packagekit-3.0.0-5.fc15.x86_64 (updates)
  4.pulseaudio-module-gconf-0.9.22-5.fc15.x86_64 (fedora)

Run transaction? [y/N] n
User declined action


After reinstalling KPackageKit, I get:

Transaction summary:
  Installing:
  1.paprefs-0.9.9-8.fc15.x86_64 (fedora)
  Installing for dependencies:
  1.gconfmm26-2.28.2-2.fc15.x86_64 (fedora)
  2.pulseaudio-module-gconf-0.9.22-5.fc15.x86_64 (fedora)

Run transaction? [y/N] n
User declined action


FWIW, I have tons of GNOME stuff installed already (even gnome-shell), so 
gnome-packagekit doesn't drag in all that much extra GNOME stuff, and 
paprefs drags in GNOME stuff by itself, too. (In fact, the kpackagekit 
package would have happened to require one less dependency, but it isn't 
even a GNOME dependency, but a PackageKit one.) But in reality, the 
dependencies are not the real issue at all, the thing is that gnome-
packagekit is useless in KDE unless you go and manually enable it. (Or at 
least it won't be fully functional, because it won't be started up 
automatically, e.g. to check for updates. It might get D-Bus-activated when 
paprefs needs it. But there are cases such as the PolicyKit 1 authentication 
agent where D-Bus activation is not used at all, exactly to ensure the 
correct agent for the running desktop environment gets used, not a random 
one.) What is actually needed to satisfy paprefs' dependency is:
= begin pseudocode =
if (GNOME installed || Xfce installed || LXDE installed)
  install gnome-packagekit;
if (KDE installed)
  install kpackagekit;
(In particular, if both are installed, install both, they're both needed 
because they'll only start in the respective desktop environment!)
if (none of GNOME, KDE, Xfce, LXDE installed)
  install a desktop environment first, or just error;
= end pseudocode =
But such complex dependencies cannot be expressed in RPM. The virtual 
dependency is only an approximation, the general assumption being that 
either gnome-packagekit or kpackagekit is already installed as part of the 
desktop in most cases anyway. So deciding based on the dependencies as yum 
does is only a heuristic, which can only be an approximation to what is 
truly needed (see the above pseudocode).


(And besides, your example is about the worst you could pick, since if 
somebody is skilled enough with package management to remove the PackageKit 
frontend, surely he or she knows what to do if zif wants to pick the wrong 
one. ;-) Real end users will ALWAYS have the PackageKit frontend installed.)

Kevin Kofler

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

Re: Zif backport repository for F15 available for testing

[Jef Spaleta]

On Tue, Sep 20, 2011 at 4:11 PM, Stephen John Smoogen wrote:

> I hope the above helps answer your question. I can install the RC2
> with a minimal install if that would help any.
>
>
Almost what I wanted :->  But appreciated.

What you have asked Is a related question. What do you get if you have
(approximately) neither kde nor gnome installed is what you asked. Clearly
yum and zif differ on that, but that is even murkier a question as to which
valid dep solution is more correct from a policy pov. I very much doubt the
end user has a well grounded expectation on which solution is more optimal
in terms of the cohesiveness of the end result.

However, packagers may care with regard to making sure they are getting
consistency between local builds and the build system we are using.

And there are related questions to the action you just did which I ask
strictly from an information gathering pov. I sincerely have no dog in this
race.
Which transaction downloaded more packages to fulfill the install? which
downloaded more bits to fulfill the install?.  (Assuming no deltas were used
in the yum transaction.) These performance tuning questions will matter for
users in some situations like metered bandwidth.


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

Re: Zif backport repository for F15 available for testing

[Stephen John Smoogen]

On Tue, Sep 20, 2011 at 16:42, Jef Spaleta  wrote:
>
>
> On Tue, Sep 20, 2011 at 2:25 PM, Stephen John Smoogen 
> wrote:
>>
>> What do you want me to do to try and test it more? Install some KDE items?
>>
>
> Remove the gnome DE stack entirely install the KDE stack, make sure
> kpackagekit is not installed and run it again.  kpackagekit is probably
> going to be installed by default if you use yum groupinstall method as comps
> tags it as a default package.
> But you should be able to uninstall kpackagekit as nothing actually depends
> on it except potentially paprefs.

Ok for this I did the following:

init 3
# yum remove "*gnome*" "*qt*" "*gtk*" "kd*" "PackageKit*"
# yum install zif
# zif by itself calls for libgnome-keyring libsoup
# zif install paprefs
... deleted output 
Transaction summary:
  Installing:
  1.paprefs-0.9.9-8.fc15.i686 (fedora)
  Installing for dependencies:
  1.PackageKit-0.6.18-2.fc16.i686 (fedora)
  2.PackageKit-glib-0.6.18-2.fc16.i686 (fedora)
  3.PackageKit-gstreamer-plugin-0.6.18-2.fc16.i686 (fedora)
  4.PackageKit-qt-0.6.18-2.fc16.i686 (fedora)
  5.PackageKit-yum-0.6.18-2.fc16.i686 (fedora)
  6.akonadi-1.6.0-4.fc16.i686 (fedora)
  7.attica-0.2.0-1.fc15.i686 (fedora)
  8.cagibi-0.2.0-1.fc16.i686 (fedora)
  9.dbusmenu-qt-0.8.2-2.fc16.i686 (fedora)
  10.   gstreamer-plugins-bad-free-0.10.22-2.fc16.1.i686 (updates-testing)
  11.   gstreamer-plugins-good-0.10.30-2.fc16.i686 (fedora)
  12.   gtk2-2.24.6-1.fc16.i686 (fedora)
  13.   gtkmm24-2.24.2-1.fc16.i686 (fedora)
  14.   herqq-1.0.0-1.fc16.i686 (fedora)
  15.   kde-filesystem-4-38.fc15.i686 (fedora)
  16.   kde-settings-4.7-3.fc16.noarch (fedora)
  17.   kdebase-runtime-4.7.0-3.fc16.i686 (fedora)
  18.   kdebase-runtime-flags-4.7.0-3.fc16.noarch (fedora)
  19.   kdebase-runtime-libs-4.7.0-3.fc16.i686 (fedora)
  20.   kdebase-workspace-4.7.0-9.fc16.i686 (fedora)
  21.   kdebase-workspace-libs-4.7.0-9.fc16.i686 (fedora)
  22.   kdelibs-6:4.7.0-1.fc16.i686 (fedora)
  23.   kdelibs-common-6:4.7.0-1.fc16.i686 (fedora)
  24.   kdepimlibs-4.7.0-1.fc16.i686 (fedora)
  25.   kdepimlibs-akonadi-4.7.0-1.fc16.i686 (fedora)
  26.   kio_sysinfo-20090930-3.fc15.i686 (fedora)
  27.   kpackagekit-0.6.3.3-2.fc15.i686 (fedora)
  28.   ksysguardd-4.7.0-9.fc16.i686 (fedora)
  29.   libglade2-2.6.4-5.fc15.i686 (fedora)
  30.   libglademm24-2.6.7-4.fc15.i686 (fedora)
  31.   libqzeitgeist-0.7.0-1.fc16.i686 (fedora)
  32.   librsvg2-2.34.1-1.fc16.i686 (fedora)
  33.   phonon-4.5.0-3.fc16.i686 (fedora)
  34.   phonon-backend-gstreamer-2:4.5.1-1.fc16.i686 (fedora)
  35.   polkit-kde-0.99.0-2.fc15.i686 (fedora)
  36.   polkit-qt-0.99.0-2.fc15.i686 (fedora)
  37.   prison-1.0-3.fc16.i686 (fedora)
  38.   qca2-2.0.3-2.fc15.i686 (fedora)
  39.   qimageblitz-0.0.6-2.fc15.i686 (fedora)
  40.   qt-1:4.8.0-0.9.beta1.fc16.i686 (fedora)
  41.   qt-mobility-1.2.0-2.fc16.i686 (fedora)
  42.   qt-x11-1:4.8.0-0.9.beta1.fc16.i686 (fedora)
  43.   qtsoap-2.7-2.fc16.i686 (fedora)
  44.   qtwebkit-2.2.0-0.1.rc1.fc16.i686 (updates-testing)
  45.   soprano-2.7.0-1.fc16.i686 (fedora)
  46.   strigi-libs-0.7.5-4.fc16.i686 (fedora)
  47.   verne-backgrounds-kde-15.92.1-1.fc16.noarch (fedora)
  48.   verne-kde-theme-15.91.0-1.fc16.noarch (fedora)
Run transaction? [y/N] n



# yum install paprefs
... deleted output...
Dependencies Resolved


 PackageArch VersionRepository Size

Installing:
 paprefsi686 0.9.9-8.fc15   fedora 62 k
Installing for dependencies:
 PackageKit i686 0.6.18-2.fc16  fedora561 k
 PackageKit-device-rebind   i686 0.6.18-2.fc16  fedora 37 k
 PackageKit-glibi686 0.6.18-2.fc16  fedora135 k
 PackageKit-zif i686 0.6.18-2.fc16  fedora 57 k
 gnome-icon-theme   noarch   3.1.90-1.fc16  fedora8.8 M
 gnome-packagekit   i686 3.1.3-2.fc16   fedora3.8 M
 gtk2   i686 2.24.6-1.fc16  fedora3.2 M
 gtk3   i686 3.1.90-1.fc16  updates-testing   3.0 M
 gtkmm24i686 2.24.2-1.fc16  fedora881 k
 libcanberra-gtk3   i686 0.28-3.fc16fedora 26 k
 libglade2  i686 2.6.4-5.fc15   fedora 60 k
 libglademm24   i686 2.6.7-4.fc15   fedora 36 k
 libnotify  i686 0.7.4-1.fc16   fedora 36 k
 notification-daemoni686 0.7.2-1.fc16   fedora 65 k

Transaction Summary

Install  15 Packages

I hope the above 

Re: Zif backport repository for F15 available for testing

[Jef Spaleta]

On Tue, Sep 20, 2011 at 2:25 PM, Stephen John Smoogen wrote:

> What do you want me to do to try and test it more? Install some KDE items?
>
>
Remove the gnome DE stack entirely install the KDE stack, make sure
kpackagekit is not installed and run it again.  kpackagekit is probably
going to be installed by default if you use yum groupinstall method as comps
tags it as a default package.
But you should be able to uninstall kpackagekit as nothing actually depends
on it except potentially paprefs.

Does zif prefer to pull in the full gnome stack to get gnome-packagekit or
does it install kpackagekit?

Easier to do if you start from a KDE only install target I guess.  I'm just
trying to test how well zif handles the multple provider case and understand
how it makes the judgment on what is installed. The most likely end user
cases I can think of are KDE/GNOME provider duality when there is a system
that has one of the desktops installed by default but not the other.   This
is just the first one I attempted and hit an unrelated bug with repodata
parsing.  Since I'm having other problems with zif depresolution I'm wary to
trust my systems until that is cleared up.  And no this might not be the
best real world example that people may hit due to kpackagekit being in the
default comps group for KDE, its just the first one I reached for as a test.
I'm sure other similar examples of the multiple provider situation exists.

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

Re: Zif backport repository for F15 available for testing

[Stephen John Smoogen]

On Tue, Sep 20, 2011 at 16:06, Jef Spaleta  wrote:
>
>
> On Tue, Sep 20, 2011 at 1:17 PM, Kevin Kofler 
> wrote:
>>
>> Jef Spaleta wrote:
>> > Kevin, were you able to reproduce my problem with the official adobe
>> > repository?
>>
>> To be honest, I haven't tried it, I've been busy enough filing the bugs
>> for
>> the issues I found myself and retesting them with today's snapshot.
>>
>
> Fair enough,  avalanche of unexpected bugs aside
>
> you have systems with just KDE and no GNOME installed yes?  zif install
> paprefs
>
> with kpackagekit not installed does zif do the more optimal thing and pull
> kpackagekit in as a dep to fill  PackageKit-session-service requirement?


On a F16 beta-ish box.. I get the following with default install:

  Installing:
  1.paprefs-0.9.9-8.fc15.i686 (fedora)
  Installing for dependencies:
  1.gconfmm26-2.28.2-2.fc15.i686 (fedora)
  2.libglademm24-2.6.7-4.fc15.i686 (fedora)

What do you want me to do to try and test it more? Install some KDE items?

-- 
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Let us be kind, one to another, for most of us are fighting a hard
battle." -- Ian MacLaren
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Zif backport repository for F15 available for testing

[Jef Spaleta]

On Tue, Sep 20, 2011 at 1:17 PM, Kevin Kofler wrote:

> Jef Spaleta wrote:
> > Kevin, were you able to reproduce my problem with the official adobe
> > repository?
>
> To be honest, I haven't tried it, I've been busy enough filing the bugs for
> the issues I found myself and retesting them with today's snapshot.
>
>
Fair enough,  avalanche of unexpected bugs aside

you have systems with just KDE and no GNOME installed yes?  zif install
paprefs

with kpackagekit not installed does zif do the more optimal thing and pull
kpackagekit in as a dep to fill  PackageKit-session-service requirement?


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

Re: Zif backport repository for F15 available for testing

[Kevin Kofler]

Jef Spaleta wrote:
> Kevin, were you able to reproduce my problem with the official adobe
> repository?

To be honest, I haven't tried it, I've been busy enough filing the bugs for 
the issues I found myself and retesting them with today's snapshot.

Kevin Kofler

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

Re: Zif backport repository for F15 available for testing

[Kevin Kofler]

Kevin Kofler wrote:
> I'm building a new snapshot of zif, which should fix #739980 (but I have
> to test that), and will be pushing it to the repository (no matter whether
> it actually fixes #739980 or not).

There's now zif-0.2.4-0.93.20110920git.fc15 in the repository, but you'll 
probably have to update to it using yum, not zif:
https://bugzilla.redhat.com/show_bug.cgi?id=740068

Sorry for that, I hope that bug will get fixed soon.

Kevin Kofler

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

Re: Zif backport repository for F15 available for testing

[Jef Spaleta]

On Tue, Sep 20, 2011 at 8:48 AM, Kevin Kofler wrote:

> I hope we can get all the annoyances in zif sorted out soon.
>
>
Kevin, were you able to reproduce my problem with the official adobe
repository?  I'm still not sure if my multiple issues with zif depsolving
are a problem with my system specifically or with zif. I'd appreciate if you
could try to reproduce what I was seeing on bug
739701.
I'll update to your backport repo and reconfirm.

Sadly... my C foo isn't as good as my python foo, so I'm not going to be
much help tracking down what is going wrong in zif's parsing of the valid
provide information in the repodata to result in bogus provides getting
mixed into its depsolving.

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

Re: Zif backport repository for F15 available for testing

[Kevin Kofler]

Kevin Kofler wrote:
> I have put up a repository with an updated zif snapshot for Fedora 15 at:
> http://repos.fedorapeople.org/repos/kkofler/zif-backport/fedora-zif-backport.repo

So, I found several issues, mostly in zif or PackageKit-zif, but also one in
KPackageKit/Apper:
https://bugzilla.redhat.com/show_bug.cgi?id=739969
https://bugzilla.redhat.com/show_bug.cgi?id=739980
https://bugzilla.redhat.com/show_bug.cgi?id=739983
https://bugzilla.redhat.com/show_bug.cgi?id=739985
https://bugs.kde.org/show_bug.cgi?id=282418

I'm building a new snapshot of zif, which should fix #739980 (but I have to
test that), and will be pushing it to the repository (no matter whether it
actually fixes #739980 or not).

I hope we can get all the annoyances in zif sorted out soon.

Kevin Kofler

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

Zif backport repository for F15 available for testing

[Kevin Kofler]

Hi,

I have put up a repository with an updated zif snapshot for Fedora 15 at:
http://repos.fedorapeople.org/repos/kkofler/zif-backport/fedora-zif-backport.repo

The repository also includes a rebuild of PackageKit to deal with the bumped
zif soname. This should only affect PackageKit-zif, but all subpackages
including the main package are rebuilt, and provided because of the strict
%{version}-%{release} dependencies.

WARNING: This is a backport repository for testing purposes. Zif in Fedora
 15 should be considered a technology preview. This repository
 updates it to a newer version, which is a major improvement over
 what's currently in Fedora 15, but should still be considered a
 technology preview. It needs all the testing it can get, which is
 the purpose of this repository.


Please note that the "zif" package itself contains only the library, you
will want one or more of the following packages, which all require zif:

* PackageKit-zif: Probably the most interesting one. Adds support for zif to
  PackageKit (and thus gnome-packagekit and KPackageKit). Please read the
  notes at https://github.com/hughsie/zif/blob/master/README.PackageKit for
  how to enable it (or just remove PackageKit-yum if you're really brave ;-) ).

* zif-tools: This contains the command-line "zif" utility, useful for
  debugging. It can also be used as a replacement for the yum command line,
  though that's not really what it is designed for. (In particular, do NOT
  expect support for all those fancy yum plugins, nor for the yum history.)
  But if you're a command-line junkie who wants something faster than yum to
  play with, you might end up liking it anyway. ;-)

* zif-devel, if you're a developer and want to use zif in your own code.
  Otherwise you'll have little to no use for this particular subpackage. ;-)


Any issues with the repository itself should be reported to me, any issues
encountered with the actual software should be reported to Richard Hughes
(by filing a bug against zif at bugzilla.redhat.com).

Kevin Kofler

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