[gentoo-dev] [gsoc-status] portage backend for PackageKit

[gentoo-dev] [gsoc-status] portage backend for PackageKit

[Mounir Lamouri]

Hi,

I'm working on a portage backend for PackageKit [1].

As I did not really present my project, you have to know PackageKit is
an universal (distribution-wide) package manager. To do so, every
package manager which wants to work with PackageKit have to follow an api.

PackageKit is compatible with a lot of package managers. Actually, it's
the default one in Fedora and some other distributions.
The main advantage of using PackageKit is to have a simple application
working in most distributions. It will be a great advantage to make
Gentoo more user-friendly. With a USE-flag GUI manager, it could be
really great.

The main difficulties for this project is the source-based aspect of
Gentoo and the verbosity of portage. I mean even if PackageKit is
designed to fit every needs, portage backend is the first source-based
distribution backend and we will have to adapt some things. In addition,
some information provided by portage like ewarn and elog messages and
new configuration files have to be prompted even when using PackageKit.

So, where are we right now ?
The planning says "every basic features should be done June 15th".
Actually, I still have to do 2 features : list update candidates and do
update. Every other basic features (install, remove, sync, details, dep,
reverse-dep, groups, ...) have been done.
To my defense, that's three days I'm sick.
In addition, as PackageKit refuses interactivity, I've pushed
ACCEPT_LICENSE default value to remove interactivity from ebuilds using
check_license function from eutils eclass.

What's going to be done right now ?
Repositories management have to be added. With zmedico, we were talking
about doing this directly in the portage api. Basically, it will be
merging layman into portage. It's not 100% sure right now but probable.
Beginning the hard work of messages management and bug fixes.

I will try, to add needed ebuilds in the tree this week to let people
test PackageKit on Gentoo as it will be "usable" even if not recommended
yet. That's what we call an alpha version I think ;)

[1] http://packagekit.org/

Thanks,
Mounir

Re: [gentoo-dev] [gsoc-status] portage backend for PackageKit

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 850 bytes --]

Mounir Lamouri wrote:
> 
> So, where are we right now ?
> The planning says "every basic features should be done June 15th".
> Actually, I still have to do 2 features : list update candidates and do
> update. Every other basic features (install, remove, sync, details, dep,
> reverse-dep, groups, ...) have been done.
> To my defense, that's three days I'm sick.
> In addition, as PackageKit refuses interactivity, I've pushed
> ACCEPT_LICENSE default value to remove interactivity from ebuilds using
> check_license function from eutils eclass.
> 

If there are interactive ebuilds that don't declare
PROPERTIES="interactive", you can just compile a list and post it to
gentoo-dev-announce telling maintainers to add it or you will do it at
some date X a week from the announcement or later at your choosing.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: [gentoo-dev] [gsoc-status] portage backend for PackageKit

[Steve Dommett]

On Monday 15 June 2009, Petteri Räty wrote:
> If there are interactive ebuilds that don't declare
> PROPERTIES="interactive", you can just compile a list and post it to
> gentoo-dev-announce telling maintainers to add it or you will do it at
> some date X a week from the announcement or later at your choosing.

I'm no Python programmer,  and I haven't even read the code involved,  but in 
the interests of minimising duplication of effort,  I thought you'd be 
interested to know that Sabayon,  a Gentoo based binary distro,  look like 
they may be one step ahead of you on this one:
http://gitweb.sabayon.org/?p=playground/packagekit-entropy.git;a=summary

Cheers,
  Steve.

Re: [gentoo-dev] [gsoc-status] portage backend for PackageKit

[Nirbheek Chauhan]

On Sat, Jul 4, 2009 at 5:05 AM, Steve Dommett<steve@st4vs.net> wrote:
> I'm no Python programmer,  and I haven't even read the code involved,  but in
> the interests of minimising duplication of effort,  I thought you'd be
> interested to know that Sabayon,  a Gentoo based binary distro,  look like
> they may be one step ahead of you on this one:
> http://gitweb.sabayon.org/?p=playground/packagekit-entropy.git;a=summary
>

It's a stub import (no real code). And the git import is also done
incorrectly, he's imported .libs/ and .deps/ which are build-time
files. So, I'd say he looked at *this* project and decided to try
writing a backend for Entropy as well.


-- 
~Nirbheek Chauhan

Re: [gentoo-dev] [gsoc-status] portage backend for PackageKit

[Mounir Lamouri]

Nirbheek Chauhan wrote:
> On Sat, Jul 4, 2009 at 5:05 AM, Steve Dommett<steve@st4vs.net> wrote:
>   
>> I'm no Python programmer,  and I haven't even read the code involved,  but in
>> the interests of minimising duplication of effort,  I thought you'd be
>> interested to know that Sabayon,  a Gentoo based binary distro,  look like
>> they may be one step ahead of you on this one:
>> http://gitweb.sabayon.org/?p=playground/packagekit-entropy.git;a=summary
>>
>>     
>
> It's a stub import (no real code). And the git import is also done
> incorrectly, he's imported .libs/ and .deps/ which are build-time
> files. So, I'd say he looked at *this* project and decided to try
> writing a backend for Entropy as well.
>
>
>   
Like Nirbheek said, there is no real code so I'm not sure they are one
step ahead of me on this project.
In addition, they should ask for a packagekit git access. It's easy to
get one and surely better than working in your own playground.

Mounir

Re: [gentoo-dev] [gsoc-status] portage backend for PackageKit

[Nirbheek Chauhan]

On Sun, Jul 5, 2009 at 8:59 PM, Mounir Lamouri<volkmar@gentoo.org> wrote:
> In addition, they should ask for a packagekit git access. It's easy to
> get one and surely better than working in your own playground.
>

I agree, Richard Hughes is really cool about this stuff, so lxnay, if
you're reading this, get in touch with him. He'd be delighted to give
you access :)


-- 
~Nirbheek Chauhan

[gentoo-dev] Re: [gsoc-status] portage backend for PackageKit

[Mounir Lamouri]

Arne Babenhauserheide wrote:
> Am Montag, 15. Juni 2009 22:51:52 schrieb Mounir Lamouri:
>   
>> I'm working on a portage backend for PackageKit.
>>     
>
> Could you give us a small status update? 
>
> Does your backend already work? 
>
> Best wishes, 
> Arn
Hi,

It has been a while without weekly updates even if my mentor suffers^W
benefits of frequent updates, I didn't get really interesting things to
be said here.
Actually, I had some issues with the last functions I had to re-write.

The backend is now ready. You should be able to do anything in a
beta/realease candidate quality.
Even if I think there are still two features that can (timely speaking)
and need (user's point of view speaking) to be added:
- configuration file update
- messages / warning / errors show
They are not critical for testing but only for a daily usage.

I've already done the portage work for the first feature but I will have
to add signal to packagekit because even if debian also needs it, it
hasn't been implemented yet. The bad thing is GUI will probably not
manage this feature since a quite long time.
The second feature shouldn't be really hard.

About the packaging. I've worked on a packagekit ebuild and even if I
didn't take time to add it to the tree it could be done without a lot of
work but there is not real need at the moment because -as I said before-
without a GUI, packagekit is quite useless and last version of
gnome-packagekit needs a version gnome-policykit that is not in the tree.
As the backend should now be working correctly for a real usage it will
probably add packagekit live ebuild in the tree but if you want to test
the backend, I recommand you to clone packagekit and gnome-packakit
repositories, it will be easier ;)

After these two features, I will probably have some small things and
bugs and I will move to big things for packagekit or portage needed to
make the backend better. Indeed, there are a lot of things I've listed
that are not really needed for a working backend and too big to be part
of the gsoc. For example, merging layman into portage (actually, API
will be easy but UI probably less) and having a non-verbose portage API
because backends are using stdout for signals.

If by any chance, you test the backend, do not hesitate to contact me
for bug reports or comments.

Thanks,
Mounir

[gentoo-dev] Re: [gentoo-soc] Re: [gsoc-status] portage backend for PackageKit

[Mounir Lamouri]

Hi,

New weekly report via answer to Arne.
This week wasn't the most productive I had. Mostly because of the ebuild
work which take easily hours (yes, I should use ccache) and because of
the summer and good weather.
But, now, you can test my work and blame me, that should make everyone
happy ! :)

Arne Babenhauserheide wrote:
>> - configuration file update
>>     
> In the means of "cfg-update -u" or similar? 
>   
[snip]
> (sorry if I sound dumb, just want to be sure I didn't misunderstand) does that 
> mean that you'll be adding the config updating stuff to packagekit, so we'll 
> have a cross-distro way of telling the package manager to update the configs? 
>   
Actually, this is going to be harder than excepted. Not technically
speaking but it looks like people (backend/packagekit dev) want
different things.
So, in a first time, I'm going to show only a message about
configuration files updated then I will take some time to discuss with
devs and fix a specification.
It looks like it will be an internal tool that will update configuration
files but possible actions and how to interact have to be defined.
So it will be a cross-distro way of updating configuration files.

> Could you post the ebuild in here? 
>   
Good news is the ebuilds are now available in the gnome overlay. Why
gnome overlay ? because they have polkit-0.93 and I needed the new
polkit version. I've updated 0.5.1 version (last release) and live ebuild.
0.5.1 should be ok for testing now because the release wasn't done long
ago and since I mostly worked on packagekit build system and ebuild.
If you found issues, please, send me a private email or open a bug but
better not flooding ml.

> I wanted to test KPackageKit since I saw it in Kubuntu :) 
>
> - http://www.kde-apps.org/content/show.php/KPackageKit?content=84745
>   
I'm going to write an ebuild for gnome-packagekit. It's surely the best
way to test packagekit because it's developed by the same guy. If anyone
wants a KPackageKit ebuild, I can help but not write it.

> I don't know if I'll manage to grab enough time to do real testing, but I'll 
> try. 
>   
Even small feedbacks are welcome ;)
PackageKit should be tested with a GUI but as I have not released a
gnome-packagekit ebuild, you have two ways to test it:
- use pkcon which is a CLI client to packagekit but really basic like if
you want to install foo package, it will install it and dependencies
without telling you if you accept them. For 'atomic' tests, it's the
best way of doing.
- build yourself gnome-packagekit shouldn't be hard at all ;)

So, this week, I will add a ACCEPT_PROPERTIES feature to portage. I was
thinking of filtering interactive PROPERTIES in my backend but zac told
me he was planning to add this feature. It should be available soon (one
or two days) and the gnome-packagekit ebuild will be the next step. So,
you should have it in two or three days. Depends on the difficulty. If
the build system is clean as the PackageKit one was, it will be hard and
I've no commit access to gnome-packagekit unfortunately.

Thanks,
Mounir

[gentoo-dev] Re: [gsoc-status] portage backend for PackageKit

[Mounir Lamouri]

Mounir Lamouri wrote:
> So, this week, I will add a ACCEPT_PROPERTIES feature to portage. I was
> thinking of filtering interactive PROPERTIES in my backend but zac told
> me he was planning to add this feature. It should be available soon (one
> or two days) and the gnome-packagekit ebuild will be the next step. So,
> you should have it in two or three days. Depends on the difficulty. If
> the build system is clean as the PackageKit one was, it will be hard and
> I've no commit access to gnome-packagekit unfortunately.
>   
gnome-packagekit is now availabe in the gnome overlay.
And ACCEPT_PROPERTIES is available in portage trunk.

I'm now fixing some bugs so if you found some, let me know !

Mounir