I wanted to provide a technical critique in relatively low-visibility but that's apparently not going to be possible now due to the actions of Rob Taylor. Rob, pointing out that the Emperor Has No Clothes seems important enough to mention it to the fucking Emperor; not "stop energy"--this exercise in a circle-jerk on Planet is. You apparently didn't bother to familiarize yourself with the technical barrier of which I am speaking: any .deb package may need access to STDIN during its installation process.
This is a long-standing policy. It's probably not the best practice but that's the way it is. This practice predates yum's, RedCarpet's, yast's and up2date's existences. To arbitrarily decide as a front-end--nay, THE front-end to end all front-ends--that you're not going to allow this to occur is the kind of hubris that comes from myopically paying attention to only the requirements of the distribution funding the project and ignoring the requirements of other systems--especially when the package management system in question is the one used by the most successful distro. to date (Ubuntu). Time and time again, RedHat manages to have this same god-damned scenario play out, year after year after year. Maybe it's not standard operating procedure to pretend that you're the only game in town, but it sure fucking looks that way from the outside.
Richard Hughes replied to my comment on his blog, thusly:
it appears that PackageKit is fundamentally incompatible with dpkgI'm sorry, but that's completely wrong. It means forcing a wrapper around dpkg to enforce a common abstraction, as we can't expect end users to interact with shells and other insane stuff like that. It's all documented in the FAQ.
This is phenomenal arrogance. Who are you to decide how distributions should implement their packaging systems? Are you going to waltz in to the highly political Debian development process and demand that the Technical Committee put to a vote a constitutional amendment requiring packages to not occasionally need input? Of course you aren't. It would never pass. It's infinitesimally unlikely that the Debian and Ubuntu ecosystems would bend their long-standing, working systems to allow PackageKit to front end them if PackageKit forces fundamental changes to packaging policy.
So, going back to Gnome module maintainership: what kind of an asshole would I be if I added code to my responsible module that only works on RedHat-derived systems? More of an asshole than I'm making myself out to look like right now, that's for sure.
Proposed solution: make PackageKit do exactly what synaptic has been doing for the past three years: when a package install process blocks on file descriptor 0, unhide a hidden VTE widget. As it stands now, none of the publicly facing Ubuntu or Debian PacketKit pages have proposed any other solution to the problem, and it appears there's no other proposed solution on the mailing list. (Take care to note that this has nothing to do with debconf.)
This has the added benefit of making it possible for any user on any distro. to unhide the VTE window when something goes wrong--and we all know that something goes wrong with package managers all the time.
When PackageKit supports more than RedHat-derived systems, I would love to support it. Let's get there before we start adding distro.-specific support all over Gnome.
Update 2008-04-14 11:46 PM: A poster who posted nine replies to this and the later post has been banned after being warned not to continue to spam my blog. All comments that display as screened
were by the banned party.
Profile
![[info]](http://p-stat.livejournal.com/img/userinfo.gif)
jasondclinton- Jason D. Clinton
Comments
http://live.gnome.org/CodeOfConduct
The most recent example in they Gnome community was probably Murray's admonition to not vote for Jeff Waugh for the Gnome Foundation board. There are plenty of other examples, of course.
Yes, what I said is ugly, but it's honest. That's something, I guess.
By your logic, GNOME should not use graphical interfaces at all, because else text-only distributions can't use it. This doesn't make any sense.
http://tieguy.org/blog/2008/04/11/secon
http://weblogs.mozillazine.org/gerv/arc
is a big mistake. Not that I pretend that you disagree these dialogs are crack, just saying these are the eye-sores that would disrupt the user in a very annoying way. But I guess you'd only get them on Debian/Ubuntu so personally I'd be fine in making PackageKit support such a dubious feature.
And, if you're so angry with Red Hat, at least take the time to spell the name correctly. Thanks.
Yes I am diehard pro-debian and I haven't even used it and derivatives more than three years; I think it already looks like debian can't and doesn't want to be part of this package-kit project. Unless this is solved.
It should be pointed out that PackageKit is driven by very modern and respectable ideals. But more homework should have been done on the point of the minimal required features, and trying to bring in all players on this. APT is not a small player.
--ulrik http://users.student.lth.se/f04us/
I dunno...this'll take some beating.
Other examples include Epiphany (no sane user ever uses more than 3-5 tabs, because I don't! No need to have manageable tabs!) and gnome-screensaver (I don't configure screensavers, so if they need it, say a text should be displayed, then they are broken!).
Don't get me wrong, the GNOME philosophy of having sane defaults and treating any preference as a potential bug is a fantastic way to do better interfaces, but sooooo many people misinterpret that as hard rules that must be enforced.
I "blame" Havoc and Joel Spolsky for writing excellent articles on the subject, but making them more than a few paragraphs so many people stopped reading them too early. At least that's my best guess at what happened.
Too bad. PackageKit sounds like a great idea. Almost as good as uniting on a common format.
If Debian/Ubuntu are moving to debconf, under which PackageKit will function with default values all hunky-dory, then what is the issue here? Is Debian/Ubuntu just pissed because they won't be getting in on the "ground floor"?
PackageKit will work with your distro when you clean up your input/default value handling, which you readily admit isn't what you want it to be and you are already in the process of migrating to something better.
Why should PackageKit have to spend resources to support some functionality/process you are in the process of migrating away from?
It seems to me like it makes more sense to continue working on your debconf migration, and PackageKit will be waiting for you when you get there. Probably further improved, since they didn't have to take time to support your older methodology which you are in the process of abandoning.
> asshole would I be if I added code to my responsible module that
> only works on RedHat-derived systems? More of an asshole than I'm
> making myself out to look like right now, that's for sure.
>
That's the one thing in your post that is completely 100% wrong. Any solution that works somewhere is better than a solution that does not work at all. And if Debian distros can't provide a good abstraction to their packaging system, it's their fault and the rest of the world doesn't have to suffer from it.
Benjamin
1. A debian package asking random questions through STDIN is a BUG. The behaviour is deprecated and should go away. PackageKit supporting this behaviour just prolongs that behaviour.
2. PackageKit supports more than just Red Hat derived systems.
3. Hughes has been trying to come up with a GOOD solution, not a solution based on old cruft.
4. Ranting like an arsehole is ridiculous behaviour regardless of whether you say you are an arsehole or not.
This is phenomenal arrogance
Severe case of pot/kettle disease
I don't know, but... Yet you people (GNOME Developers in general) do this *constantly* by adding incompatibilities with non-Linux systems. (Think BSD or Solaris.) GNOME behaves very badly in any of these systems and gives a very bad impression of them because even the most trivial things do not work due to the amount of "abstraction" layers in between that are completely focused on Linux.
It's also a very serious security problem. Especially when the Ubuntu guys run the entire GNOME application that hosts the VTE widget as root (which they do, and which is stupid).
Not only that, they also run the apt-get and/or dpkg process as root in that window under a shell. And not only that, they also made the VTE widget writable. So I can send from a user-program a CTRL+C to the apt-get or dpkg process and get a root shell back.
Being a programmer I can come up with hundreds of possible vectors to exploit that.
Ubuntu is just lucky that they don't have as much users as Microsoft Windows has.
-- Philip Van Hoof, software developer and GNOME contributor who doesn't want to make LiveJournal and/or OpenID accounts.
Yet I do probably know about the code that is involved (The VTE widget and the GNOME libraries), that I do know that the GNOME libraries are absolutely not designed with security in mind. I also do have multiple examples in the code that show, very clearly, that the GNOME libraries are absolutely not designed with security in mind.
I even have an E-mail by one of the original VTE developers stating that running a VTE widget as root in a predictable way, hidden or not hidden, is absolutely and definitely a serious security risk.
The person sent me that E-mail as a response to an announcement that I made about GNOME Xsu, which was a gnomesudo-like application that I made several years ago and that also used a VTE widget to send the password to the SU binary.
So please don't start replying: "then file a bug, bla bla bla"
When you do file a bug about this, they (Ubuntu people) will close it quickly.
I even proposed an ad-hoc solution for this: working with a SUID root binary that gets commands from the user-process, rather than running the entire GNOME application with sudo (therefore, as root).
I think PackageKid's solution is even better: provide a good and standardized framework for those questions, let it use an IPC (which is what the "gets commands from the user-process" would have been about, too).
It's actually the right architecture for this.
Having a hidden VTE widget in a GNOME application that runs entirely as root, is creating a situation that can be exploited in hundreds of ways.
It's a ticking time-bomb that will leave the Ubuntu developers in awe as soon as somebody actually does make a working exploit for this. For example when Ubuntu indeed has a really huge user-base (under the assumption hat this will happen).
-- Philip Van Hoof
Just for your notice, Farsight is no RedHat-derived system. And they're using PK by default.
just look how many kernel developers they employ and how many patches they contribute to upstream and compare it to others. also, they make it really easy to create RHEL derivates like Centos.
Fedora has a policy to try to do as much as possible upstream afaik which is good. this way, other distributions like debian and ubuntu profit very fast from it.
you may also want to have a look at http://fedoraproject.org/wiki/RedHatCont
understand it, red hat is NOT evil, you are profiting from it on your linux desktop.
also, packagekit would work fine with APT and DPKG if the dpkgs would be fixed up (mentioned above). so theretically, PK's architecture is fine.