[packagekit] Packagekit and Ubuntu

Sun Sep 20 08:29:44 PDT 2009

Would be awesome if any updates or progress on this could be posted to this mailing list as this discussion seems to have turned out very positive and hopefully this will come to fruition and this ship doesnt sink here.

@Michael,

Do you its possible something may be ready for testing in Karmic +1, possibly a PPA? Or would we be looking at a time frame longer than that?

> Date: Fri, 18 Sep 2009 13:59:33 +0100
> From: hughsient at gmail.com
> To: packagekit at lists.freedesktop.org
> Subject: Re: [packagekit] Packagekit and Ubuntu
> 
> 2009/9/18 Michael Vogt <mvo at ubuntu.com>:
> > In some (rare) cases the sane default is to not allow the package to
> > get installed. This was the case for the virtualbox package at some
> > point where a new version would destroy the old snapshots. So using
> > sane defaults sometimes means a package can not be installed at
> > all. Admittedly those are rare cases, but we do want to support them
> > with our tools.
> 
> Sure, in that case I would argue to abort the install with
> ERROR_CODE_NEED_NATIVE_TOOL which prompts the user to use the native
> tool to do this as it's dangerous. I don't think asking the user to
> use a command line tool is insane when we are not supporting all the
> options and functionality of apt-get.
> 
> > I agree with that for 99% of the users, but I would like to support
> > 100% of our users. If its useful for more experienced users or setups,
> > then I don't see why we have to limit ourselfs (this assumes of course
> > that it does not make the api totally horrible, but I don't think that
> > this is the case).
> 
> Right, if the code addition is small (or well contained) then it's fine for me.
> 
> > This is a good example and it shows a weakness. I do think it can be
> > adressed by e.g. forcing codecs (or fonts) to
> > DEBIAN_FRONTEND=noninteractive and only allow different settings for
> > the "do-anything" case.
> 
> Right, the issue is that transactions can be started in an interactive
> mode, and then become non-interactive (for instance when we do fast
> user switching) and vice versa, so it's difficult to know upfront what
> policy to choose. This is why I think an explicit policy is the best
> plan (see below).
> 
> > If the user decides to get automated updates in the background then
> > this is fine. If the users wants updates in a interactive way, I think
> > we should not disallow debconf prompts for him, they may be good and
> > useful (or may not, but its hard to predict that).
> 
> Sure, I would be happy to add an option to /etc/PackageKit/apt.conf,
> UseDebconfFrontend, but obviously default to false for desktop use
> cases.
> 
> > I will have to look into the code to see how to map it to PK. The
> > support in aptdaemon is relatively unobtrusive. There is no need for a
> > vte root window.
> 
> That's good to know. If more people knew that synaptic was running
> with a hidden vte running as root, then more security guys would start
> running around with their arms in the air.
> 
> > With debconf, the transaction may hang because it is waiting for input
> > from the user. Usually debconf questions are asked upfront, but it may
> > happen that they are asked during install (because the maintianer
> > scripts do odd things). I take from the above that this is still oK?
> 
> Sure upfront questions are great. We already do upfront questions like
> GPG signing in Fedora.
> 
> >> 2. Don't let them bully you into making PK just as bad as what was
> >> previously done
> >
> > You use strong word here (I'm not a native speaker, so I may be
> > wrong). I don't think we "bully" you, we ask about features and we
> > offer help to implement them to make PK map to the deb world. The fact
> > that Sebastian went through the pain of doing aptdaemon shows IMO that
> > it is a important requirement.
> 
> Sure, bully is a strong word, but there's a lot of powerful ego
> (myself included) in open source projects. Luckily, I'm a cheery sort
> of person who very rarely gets angry. :-)
> 
> > How much it hurts the API remains to be seen while implementing it. So
> > far PK did not receive a warm reception in the deb world because it
> > does not map well to the requirements of the deb world.
> 
> Right, and that's probably partially my fault for not running a
> deb-based distro from day to day.
> 
> > Again, some debconf questions are bad, but that does not mean we
> > should throw it out entirely. The admin/distros are still free to set
> > it to noninteractive. But I think the default tool to install packages
> > should be able to deal with all valid (deb) packages. And that
> > includes debconf questions. The fact that it does not currently is the
> > only reason we do not ship it by default (and that debian does not
> > have it at all).
> 
> Right. And the shipping by default bit is the important part for me.
> It's very hard to convince applications to use PackageKit, when you
> can't say "it's present on all distros" and instead you're saying
> "it's on some distros". Classic chicken and egg.
> 
> > Thanks, I think we should continue the discussion ones there is some
> > code to show. I'm pretty happy with the discussion.
> 
> Cool, I think this is an important discussion too, and I do value your input.
> 
> > The Debian/Ubuntu packaging tools evolve as well :) There should be no
> > need for that anymore. While it still may be for some really old
> > package its a deprecated "feature" that a terminal needs to be
> > available (this was different in the past, but that is past now).
> 
> That's good to hear.
> 
> Richard.
> _______________________________________________
> PackageKit mailing list
> PackageKit at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/packagekit

_________________________________________________________________
Feeling the financial pinch? Check on MSN NZ Money for a hand
http://money.msn.co.nz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/packagekit/attachments/20090921/4dd59834/attachment-0002.htm>