Since Pirut has been replaced with PackageKit, and we already have a
GSoC student working on adding service pack support to PackageKit [1],
it does not make sense to keep Opyum [2] anymore in the distribution.
Therefore I would like to retire the package from Fedora 9 and
Rawhide.

Before someone jumps up and asks how Opyum made it into Fedora 9 when
Pirut (a critical dependency) is missing, let me tell you what
happened.

Jeremy Katz had been nice enough to notify me during the Fedora 9
cycle about his plans of retiring Pirut. However none of the
subsequent rawhide reports till date mentions opyum's missing
dependency on pirut. This had led me to believe that for some reason
Fedora 9 had still retained Pirut, until I got this:
https://bugzilla.redhat.com/show_bug.cgi?id=448324 Since the rawhide
reports are usually accurate, I fear I might have dropped the ball
somewhere and made a fool of myself.

Does anyone have any objections?

Happy hacking,
Debarshi


[1] http://code.google.com/soc/2008/fedora/appinfo.html?csaid=58FD27FF194214DD
[2] http://fedoraproject.org/wiki/DebarshiRay/Opyum

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Debarshi Ray <debarshi.ray <at> gmail.com> writes:
> Therefore I would like to retire the package from Fedora 9 and
> Rawhide.

Well, the package can't be removed from the Fedora 9 Everything repository,
that repository isn't allowed to change (because changing it would cause
mirroring chaos).

It can be blocked from Rawhide though, ask rel-eng for that.

> Jeremy Katz had been nice enough to notify me during the Fedora 9
> cycle about his plans of retiring Pirut. However none of the
> subsequent rawhide reports till date mentions opyum's missing
> dependency on pirut. This had led me to believe that for some reason
> Fedora 9 had still retained Pirut, until I got this:
> https://bugzilla.redhat.com/show_bug.cgi?id=448324 Since the rawhide
> reports are usually accurate, I fear I might have dropped the ball
> somewhere and made a fool of myself.

The problem there is that gnome-packagekit has:
Provides: pirut = 1.3.30-3
without actually providing the Python modules pirut used to provide. So there's
no broken dependency, Opyum just fails at runtime (and is thus completely
useless), but the dependency checkers won't catch it.

Kevin Kofler

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Kevin Kofler wrote:

The problem there is that gnome-packagekit has:
Provides: pirut = 1.3.30-3


Would a "Obsoletes: pirut" have been more accurate and appropriate here?

Just thinking about ways we could maybe prevent this from happening again.

-Jeroen

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Jeroen van Meeuwen <kanarip <at> kanarip.com> writes:
> Would a "Obsoletes: pirut" have been more accurate and appropriate here?

There's both an Obsoletes and a Provides, the Obsoletes makes sense, the
Provides not really, and it causes issues like this.

Kevin Kofler

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Kevin Kofler wrote:

Jeroen van Meeuwen <kanarip <at> kanarip.com> writes:

Would a "Obsoletes: pirut" have been more accurate and appropriate here?


There's both an Obsoletes and a Provides, the Obsoletes makes sense, the
Provides not really, and it causes issues like this.


It would sort of make sense to be able say in a spec:
Provides: pirut(functionality)
ie equivalent functionality = gui package management
rather than the pirut(api) ?

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Sun, Jun 8, 2008 at 8:51 PM, David Timms <dtimms@iinet.net.au> wrote:
> Kevin Kofler wrote:
>>
>> Jeroen van Meeuwen <kanarip <at> kanarip.com> writes:
>>>
>>> Would a "Obsoletes: pirut" have been more accurate and appropriate here?
>>
>> There's both an Obsoletes and a Provides, the Obsoletes makes sense, the
>> Provides not really, and it causes issues like this.
>
> It would sort of make sense to be able say in a spec:
> Provides: pirut(functionality)
> ie equivalent functionality = gui package management
> rather than the pirut(api) ?

Obsolete: pirut -> pirut is dead, this replace pirut, other apps that
depends on pirut - break their dependencies
Provides: pirut -> pirut is still alive, this package now include
pirut, other apps that depend on pirut - retain dependencies

>
> --
> fedora-devel-list mailing list
> fedora-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



--
Mohd Izhar Firdaus Bin Ismail
Amano Hikaru
天野晃 「��� ��る�
http://fedoraproject.org/wiki/MohdIzharFirdaus
http://blog.kagesenshi.org
92C2 B295 B40B B3DC 6866 5011 5BD2 584A 8A5D 7331

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Sun, 8 Jun 2008, David Timms wrote:


Kevin Kofler wrote:

Jeroen van Meeuwen <kanarip <at> kanarip.com> writes:

Would a "Obsoletes: pirut" have been more accurate and appropriate here?


There's both an Obsoletes and a Provides, the Obsoletes makes sense, the
Provides not really, and it causes issues like this.


It would sort of make sense to be able say in a spec:
Provides: pirut(functionality)
ie equivalent functionality = gui package management
rather than the pirut(api) ?


"Pirut" is just a name and an implementation detail, you'd want something
along the lines of "Provides: package-manager-gui" similarly to httpd
providing "webserver" etc, that apps just wanting a GUI package manager
can depend on. Blindly adding provides for everything obsoleted is just
BAD, unless they actually provide a compatible interface (be it API or
command names).


- Panu -



--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Mon, 2008-06-09 at 10:35 +0300, Panu Matilainen wrote:
> On Sun, 8 Jun 2008, David Timms wrote:
> > It would sort of make sense to be able say in a spec:
> > Provides: pirut(functionality)
> > ie equivalent functionality = gui package management
> > rather than the pirut(api) ?
>
> "Pirut" is just a name and an implementation detail, you'd want something
> along the lines of "Provides: package-manager-gui" similarly to httpd
> providing "webserver" etc, that apps just wanting a GUI package manager
> can depend on. Blindly adding provides for everything obsoleted is just
> BAD, unless they actually provide a compatible interface (be it API or
> command names).

Although it does make the point that we should dig out the python
auto-provides/requires and see about enabling them again. That would
then add the fact that pirut had provided a certain API which was
required by things.

Jeremy

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list