Tony White:
To integrate "proper" with nix-env and the rest of it, would
probably take C++ and a libnix.so and a real Qt interface ?
Hi all,
Packagekit might be the way to go I believe :
http://www.packagekit.org/pk-intro.html
The ui can be left to the respective developers and user selection
that way.
There are both gtk and qt4 front ends for packagekit.
http://www.packagekit.org/gtk-doc/index.html
Actually it has gnome and kde4 frontends, but whatever.
(integrated upstream, as part of http://freedesktop.org)
libpackagekit is obviously written in C but I would like to think that
in their source repo, somewhere, there could be some method of using
perl to interact with libpackagekit (Or python or maybe ruby.)
Bindings of some sort or using dbus bindings, possibly.
The urpmi backend uses perl and ports backend uses ruby,
but only python has generic support in the PK library...
If you look at the back end matrix :
http://www.packagekit.org/pk-matrix.html
Not a single package type can perform the roll back feature, something
nix can do.
True. So Nix might be a useful addition to PK that way.
Hacking something out in Perl shouldn't take too long ?
It could serve as a prototype for writing a real backend,
as writing suck a "dispatched" backend goes much quicker.
I personally am not totally sold on packagekit but only because it is
not quite stable enough to be used in production. It was pushed onto
Fedora users a while ago, when it clearly wasn't ready. It still
isn't. That doesn't really apply to a distro like NixOS and it could
potentially provide an easy graphical tool for users of the nix
package manager on other distros.
It's also a way to browse packages and updates, even if not
using it for the actual installation ? And it allows source
based distributions for backends, like e.g. Gentoo's portage.
I wouldn't say it's a total interface replacement, though...
It should become good after a bit more development or at least provide
the basis for a workable fork in the future. With most of the other
distros having a back end for it now and the amount of work it saves
writing a package manager ui, why not give it a shot?
If not, I will have a go eventually, when I get round to learning a
bit more C.
Writing a whole set of tools for graphical package management seems
like a lot of work, especially seeing how packagekit could take a
large amount of the grunt work out of it.
What do you think? Is packagekit workable?
Sure. I've written a backend for FreeBSD's "ports" (using ruby)
and Slackware's "slapt" (using C), so that is certainly doable.
I think it should use C++ and talk directly with Nix, for speed.
Might give it a shot later, when I get more familiar with NixOS.
--anders
_______________________________________________
nix-dev mailing list
[email protected]
https://mail.cs.uu.nl/mailman/listinfo/nix-dev
