[packagekit] Gentoo backend

[Richard Hughes]

On Thu, 2007-11-15 at 00:47 -0800, Donnie Berkholz wrote:
> 1. Joe installs Gentoo, and at install-time, he uses one of the many 
> available methods to configure his feature settings (USE flags). After 
> that, he pretty much sticks with his original setup. We'll treat 
> changing features as a rare occurrence and posit that it occurs much 
> less often than installing, removing, updating, searching or checking 
> for updates. I don't see enough reasons these two actions need to be 
> part of the same tool; let the USE-flag editors do one thing and do it 
> well.

Totally agree, changing USE flags is not in the scope of PackageKit.

> 2. Bob's site uses Gentoo, but he's not the admin. He is a developer, 
> and he needs to install or update programs on a fairly regular basis. 
> Using PolicyKit should work out pretty well to allow him to do this in 
> the framework of Portage without giving him too many privileges.

Yes, exactly.

> Some issues I'll need to deal with:
> 
>   - During transactions, various output spits out, some of which should 
>   be read. It can also be logged, so I was thinking of just showing the 
>   log or telling people to read it post-transaction.

Well, I don't want to have a "log" to read, but I do see the benefit of
"messages" that can be nicely abstracted like we already do the error.

For instance, we could have a message:

message notice config-file-changed /etc/X11/xorg.conf long text to
explain what we need to do;another line of text

Or

message warning requires-configure-before-used ntpd;0.0.1;i386;data The
ntpd daemon needs to be configured before it can be used

It idea being that message descriptions can be localised (because the
type is enumerated) and can be show _after_ the transaction has
completed in the correct UI framework. This framework would be a gtk
window if installed with pk-application, a libnotify window if updated
automatically, or QT widget if using QPackageKit.

Using enumerated types also lets the session user decide if the message
type is useful, by having a "do not show me this type of message again"
button on the notification.

>   - At the end of a transaction, the number of config files to update is 
>   shown. That needs to get displayed in PackageKit.

The number of files? Could that use messages like above?

>   - Checking for updates in Gentoo requires a fairly large rsync of 
>   150,000 files. That means it's something we don't want to do 
>   frequently. There is a timestamp file we can check without that huge 
>   sync, but that only tells us whether the sync is newer, not whether it 
>   affects us in any way.

Sure, we've got an update cache that we use already. In the conary
backend checking for updates is also expensive and so the dameon timeout
is made larger (so the daemon takes longer idle before it exits) so that
the cached results are shown.

> Gentoo's got three decently working package managers. I'll probably try 
> pkgcore at first, since it's got a clean and stable Python API, it's 
> fast and I'm already somewhat familiar with it. I see that numerous 
> backends use Python, so there's already a nice set of examples.

Sure. The easiest to use is the python backend, although C (box) and C++
(apt.old and zypp) are also pretty easy as there are nice threading
helper functions to use.

> I think there's a need for doing simple tasks simply, even in a distro 
> like Gentoo. I'd appreciate any comments or suggestions you may have, or 
> any particular backends that may be better to base my work from.

Well, it sounds like you know the plan; it all seems very sane to me. As
long as the installing of packaged in gentoo is question free then I
think you are all set to start pushing a backend into git. I'm always
very keen on people getting work into the development server earlier
rather than later to prevent conflicts, even if it's just stub code that
doesn't do much yet. If you email me (offlist) your chosen username and
public ssh key I'll give you access to the packagekit.org development
server where you can push your work for review.

Thanks,

Richard.