[packagekit] Anjuta and PackageKit

[Sebastian Heinlein]

Am Mittwoch, den 29.10.2008, 14:32 -0400 schrieb James Antill:
> On Wed, 2008-10-29 at 08:41 +0000, Richard Hughes wrote:
> > On Wed, 2008-10-29 at 11:47 +0530, Debarshi Ray wrote:

> > > Right now, I am only the Fedora packager of Anjuta and a few of its
> > > dependencies. So where should I start if I were to work on something
> > > like this.
> > 
> > Well, you've got an initial big choice:
> > 
> > * session helper
> > * system core
> > 
> > The first gives you a nice fire and forget interface like
> > 
> > /* execute sync method */
> > ret = dbus_g_proxy_call (proxy, "InstallPackageName", &error,
> > 			 G_TYPE_UINT, xid, /* window xid, 0 for none */
> > 			 G_TYPE_UINT, timestamp, /* action timestamp, 0 for unknown */
> > 			 G_TYPE_STRING, "pygtk-devel",
> > 			 G_TYPE_INVALID, G_TYPE_INVALID);
> > 
> > This pops up a window a bit like this:
> > http://packagekit.org/img/gpk-client-codecs.png where the user is asked
> > to confirm the action, and then agree to any EULA or GPG signing
> > questions. When the software is installed, we return TRUE, else you get
> > return FALSE and a nice error code and description.
> 
>  But, IMNSHO, this is a terrible solution to the problem. Apart from
> looking like an API created by a 13yr old on a sugar high, the above
> makes the calling package automatically dependant on dbus ... and not
> anything PackageKit related.

You already demonstrated that you don't like PackageKit before, so there
is no need to insult people.

Isn't it possible to add dependencies to a RPM package manually which
are not auto detected by the build tools?

>  Also, as the rest of this thread shows, there's no good way to pick a
> good 9th (9th!) argument. None of the proposed hacks would work for:
> "./configure && make && make install" ... which kind of makes the whole
> point of PackageKit seem moot.

Do you refer to the built of Anjuta or additional software?

It is up to the Anjuta developers to add a corresponding check for an
installed packagekit to their configure.ac. I don't think that this is a
show stopper.

In the second case you should just package the software. PackageKit is
an enhancement to the current infrastructure and won't replace
distributions.

>  I would normally just wait for it to be fixed, but it looks like you're
> proposing the solution as basically done ... when it doesn't look to
> have really started, yet.

You could argue and think about this topic for years and nothing would
happen. Thanks to Richard he didn't do so. Sometimes you just have to
start and provide an attractive base solution which can be still
extended.

Cheers,

Sebastian