Le mardi 25 novembre 2008 à 18:26 +0000, Richard Hughes a écrit : > No misunderstanding, sorry. APT is the only packaging system that > formally _requires_ free input from the user, blocking in the > transaction. This is wrong. Any package that does that is considered buggy. I don’t think there is any such package remaining in lenny. > PackageKit does allow you ask certain questions, in a _structured_ > way, something like this: http://www.packagekit.org/img/gpk-eula.png I still don’t understand why you are restricting it to a single category of questions. Debconf allows that and much more, in a (of course) structured way. > It just won't open a terminal. Opening a terminal as the root user > would be so broken for a GUI tool. Note, an admin can still use the > apt command line in a terminal, if the package "won't install" using > the GUI tools. Synaptic won’t open a terminal either, except on request, for informational purposes. > Sure, PackageKit doesn't aim to replace all the functionality of all > tools, for that would be insane indeed. Power users don't have to do > everything in a GUI. If you want to restrict the scope of a package manager to what can be done by a cron job [0], I’m not sure we will find it very exciting. The design that delegates all the clever job to backends allow to do much more than that, so why are you deliberately restricting yourself? Furthermore it sounds strange to advocate at the same time that people don’t run a GTK+ app as root, and to ask to use something else than PackageKit to do complex operations. Is secure design only good for small operations? Or maybe you think distribution upgrades can only be done with a CLI? > > Currently it deliberately violates > > our policies despite all attempts at discussing it, and it would be kept > > out of the testing branch as soon as it is uploaded. > > Right, sure, it violates an arcane spec that says a package manager > should provide a VTE for packages that don't use debconf. This was my > design decision and totally deliberate as it would make most of the > cool-stuff impossible. http://www.debian.org/doc/debian-policy/ch-binary.html#s-maintscriptprompt Anything else is buggy. No one is going to blame PackageKit for not being able to upgrade buggy packages. > You don't have to fork PackageKit to make it "work" with Debian, you > just write a backend and fix your spec. You are not going to make us change our policy just because you want to restrict what a package manager can do to the level of second-grade distributions. The one thing that needs fixing in the policy is that it allows free-form input in a paragraph while forbidding it in another one. > Ubuntu are quite prepared to work _with_ the PackageKit developers > rather than _tell_ us what legacy features we have to support. I don’t recall having asked anyone to implement anything for us. However I do recall being explained that, if implemented, debconf support would not make it into your code. These kinds of little sentences are precisely the hostility I was talking about. You grew hate for the very idea of correctly supporting Debian based on false ideas of what our requirements are, and ignored any further attempts of explanations. [0] http://packages.debian.org/lenny/unattended-upgrades -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `- our own. Resistance is futile.
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
