Planet Sabayon Linux

Mad people following the SVN RSS of Entropy may have already noticed what I am writing about here below. A lot of new stuff is merging into TRUNK and I’m now here to share my excitement with you! Let’s start, here’s a quick list

• Dropped portageTools library in favor of SpmInterface class which loads a Gentoo-compatible package manager API class. In this way, we’ll be able to support other “backend” package managers such as paludis and pkgcore (by just reimplementing the existing PortageInterface class). No, Entropy does not use a Spm backend for actions handling (install,remove), so stop saying that. It uses Portage to spawn pkg_{pre,post}{inst,rm} phases and to update /var/db/pkg (vdb).
  So to speak, to get a Spm instance, just use: EquoInterface.Spm()
• Made updating repositories as user possible. This unlocked a lot of things, especially on the Notification Applet. Any user in the “entropy” group will be able to use it and run “equo update”. So, the applet will always keep your repositories updated.
  This made mandatory the need of having lock files, so I also had to implement them too.
• Moved tables PRIMARY KEYS to “INTEGER PRIMARY KEY AUTOINCREMENT” (SQLite speaking), this will allow us to provide differential repository updates on demand. In fact, EAPI=3 (as in Entropy API revision 3), will need a (server side) web service which will handle updates requests. Client will tell Server: “hey I have revision 30, gimme the latest”, Server will answer: “here it is a SQL, run it and you’ll be fine”. As usual, if an EAPI step will fail, Entropy will automatically fall back to “current EAPI” minus 1 (technically SPEAKING! Lol). So, if EAPI=3 fails, EAPI=2 will be used and so forth down to 0.
  Anyway, this is probably Entropy 0.14 stuff, but will have the “side” effect to reduce bandwidth and the needed time for users to update repositories.
• Server Socket Interface: this still needs policy handling and more supported commands, apart from this, it’s really really a cool thing. This is probably one of the first cool things that will land into the Entropy codebase. Imagine to have 20-30 computers and you need to control updates remotely or install/remove stuff. Imagine to have an issue which involves packages and you are competely a n00b, you will be able to “press” a “Help ME!” button on Spritz and allow friends to connect and fix things for you. Isn’t that enough to start screaming? Eheh
• Caching, this affects Spritz directly. I’ve really improved caching speed and general management, allowing Entropy to not trash it every now and then, so (again) to speak. Yes, Spritz will get faster and faster.
• Improved database indexes, after hours of benchmarks and mostly thanks to Michele, we’ve been able to remove useless SQL indexes and just keeping the good ones. Have you ever noticed a lag between Equo’s fetch and install steps? Well, it’s gone, completely. Cool, huh?

So, things in the TODO are still a lot, and we need YOU, Python/SQL experts!
I plan to tag Entropy 0.13 as soon as possible and start (eventually) the second refactoring, this time, server side codebase (Entropy 0.14)

Anyway, we’ll have a server migration probably tonight, OpenVZ will allow us to do it seamlessly but new DNS will have be propagated anyway (read PLEASE BE KIND AND PATIENT ).