Hello,
There is one thing I hate a lot : answering stupid questions. It makes me loose
my time and I certainly do not like that !
The problem is that slack-get is asking stupid questions ! Take the
dependencies tracking for example :
Even if it find a package with the exact name you requested it propose to you
all the matching results.
And one other thing I really don't like in slack-get (and maybe in other
package manager) is that if it find the same package on more than one media it
asks you to choose one.
I do not like that because it is typically something which can be decided by
software itself. If I talk about slack-get, there is a simple way to prefer one
media to another : you have to fill a <official-media>
tag in the configuration file ! I mean, it is an obvious way to prefer this
official media and not bother user asking him if he prefer to install amarok
from Slackware's official servers or from linuxpackages.
But since, yuo can actually prefer this I added a new feature to the media
system : a ranking system.
You can now add a <rank> tag in the medias.xml file
(inside a <media></media> group), with an integer
inside. Since it is a rank, the smaller the number is the highest priority the
media get.
In a near futur (this week at most), I will implements the following new
decision algorithm in the dependencies tracking and package
installation/upgrade systems :
- if there is more than one result for a package check :
- check if there is packages with their name
exactly equal to the request select them
- if their is more than one package like that
(name == request) :
- check if the medias
use ranks
- if yes, then select the package with the highest rank (the smaller number
inside <rank></rank>)
- if not, check if the official-media have the requested
package
- if yes, select the package
- if not, ask user to choose a package
- else if there is only one, select this
package
- else (there is no package where name ==
request), ask user to choose between the original search results.
- else (there is only one response) select the package.
I think this algorithm, will help to not stupidly bother users by asking
unnecessary questions. And since I am fully aware that some users will not like
this automated thing, I will also add a configuration key and a command line
option to allow them to enable/disable this system.
That's all for today !
See ya' for the slack-get development diary #8.
Arnaud Dupuis
Tag - sg_daemon
Tuesday 9 September 2008
Another new feature in slack-get media system
By Arnaud Dupuis on Tuesday 9 September 2008, 10:35 - slack-get
Sunday 7 September 2008
slack-get feature highlights #3 : add FTP credentials to your medias.xml configuration file.
By Arnaud Dupuis on Sunday 7 September 2008, 11:32 - slack-get feature highlight
Hi,
Today, I will highlights a brand new mechanism in slack-get : how to add your FTP credentials to the medias.xml confniguration file.
First let's remind how was the ftp authentification mechanism before.
In the old ages, you had to fill a section in the config.xml file. The section look like that :
<network-parameters>
<ftp>
<login><![CDATA[anonymous]]></login>
<password><![CDATA[slack-get@infinityperl.org]]></password>
</ftp>
</network-parameters>
This section (in the <common> configuration bloc) is (still) used by the sg_daemon to authenticate himself on FTP server (this is the global credentials).
But you may have to provide particular credentials for one ftp server, so I added the possibility to use the standard URL syntax in the medias.xml file.
So starting from the svn revision 198, you can use the ftp://<login>:<password>@<some ftp server> syntax in your medias.xml file.
The specific credentials, of course, prevails on the globals ones.
On a developper side now, this trick is done by the Slackware::Slackget::Network::Connection->parse_url() method. This is a specific case of the ftp so far but I can easily make it available for any protocols if there is a need to do so.
I plan on testing, in this parse_url() method, the availability of a __parse_url() method drivers' specific. This could help to develop specific drivers with specific url format.
I will think about that.
That's all for today ! Enjoy the end of the week end !
Arnaud Dupuis
Today, I will highlights a brand new mechanism in slack-get : how to add your FTP credentials to the medias.xml confniguration file.
First let's remind how was the ftp authentification mechanism before.
In the old ages, you had to fill a section in the config.xml file. The section look like that :
<network-parameters>
<ftp>
<login><![CDATA[anonymous]]></login>
<password><![CDATA[slack-get@infinityperl.org]]></password>
</ftp>
</network-parameters>
This section (in the <common> configuration bloc) is (still) used by the sg_daemon to authenticate himself on FTP server (this is the global credentials).
But you may have to provide particular credentials for one ftp server, so I added the possibility to use the standard URL syntax in the medias.xml file.
So starting from the svn revision 198, you can use the ftp://<login>:<password>@<some ftp server> syntax in your medias.xml file.
The specific credentials, of course, prevails on the globals ones.
On a developper side now, this trick is done by the Slackware::Slackget::Network::Connection->parse_url() method. This is a specific case of the ftp so far but I can easily make it available for any protocols if there is a need to do so.
I plan on testing, in this parse_url() method, the availability of a __parse_url() method drivers' specific. This could help to develop specific drivers with specific url format.
I will think about that.
That's all for today ! Enjoy the end of the week end !
Arnaud Dupuis
Friday 5 September 2008
Another huge bug discovered and fixed in slack-get !!
By Arnaud Dupuis on Friday 5 September 2008, 19:06 - slack-get
Hi,
Today I was going to improve (let's say "finish") the dependency tracking system, which is not good enough yet, and I ran into something very very bad...
Before doing anything with the package system, I all the time modify my medias.xml and add a local repository wich contains only one package and it's dependency tree.
Doing this I found a pretty importantly bad bug. This one is described on the slack-get bugtracking system on Sourceforge.
In one word the Slackware::Slackget::Connection's drivers system was completly bugged and had a very important namespace corruption wich was leading to a massive code malfunction.
So far, I strongly recommend to update your local SVN copy.
Fortunatly I fixed this in the latest SVN revision (198).
I hope that I will not found any other surprises like this one !
Arnaud Dupuis
Today I was going to improve (let's say "finish") the dependency tracking system, which is not good enough yet, and I ran into something very very bad...
Before doing anything with the package system, I all the time modify my medias.xml and add a local repository wich contains only one package and it's dependency tree.
Doing this I found a pretty importantly bad bug. This one is described on the slack-get bugtracking system on Sourceforge.
In one word the Slackware::Slackget::Connection's drivers system was completly bugged and had a very important namespace corruption wich was leading to a massive code malfunction.
So far, I strongly recommend to update your local SVN copy.
Fortunatly I fixed this in the latest SVN revision (198).
I hope that I will not found any other surprises like this one !
Arnaud Dupuis
Wednesday 13 August 2008
slack-get development diary #6
By Arnaud Dupuis on Wednesday 13 August 2008, 11:35 - slack-get development diary
Back from a long silence period, here it is : the 6th opus of the
"slack-get development diary" !
There is a lot of new things that I need to talk about !
First the bad news : I saw on CPAN reports that the "fix" I made for Slackware::Slackget to properly test on Solaris OS is not working.
That is a bad thing but... I don't really see the purpose on trying to fix an issue on an OS which is not a Slackware based one and not even a GNU/Linux OS ! The Slackware::Slackget module will never be usefull on this OS, so since I have no Solaris to test I will just forget about it (unless somebody provides me with a patch for this system.
Now for all the good news :
So from now on, you can start a daemon and do a
That's a very important point but it's nothing worth talking about without the dependencies tracking system.
Talking about that...
This part still need to be tested and there is no guarantees, so far, that it is working properly in all cases.
But so far my tests where very promisefull ! I add no problems and for the moment I have not yet discovered any bugs in this feature.
Again, that does not means that I will not uncover bugs later.
This feature works well and is totally automatic : if sg_daemon do not find the Slackware Project's key in the user's GPG keyring, it download it and import it. Nice and easy.
The goal of this command is to provide more informations about a package. Here is an usage example :
This little example, allow me to introduce the new command line option : --media. This one allow you to restrict the "search" or "info" commandes to the choosen media (in the previous example I wanted only results from the Slacky.it website).
Last about the slack-get cli client, I fixed lots of "non closing bugs". The non closing bugs are an annoying problem of slack-get cli client.
While the whole system became multitasks, it's becomming difficult to keep track of what the client asked by itself (particularly in a multi-administrators context), and after asking a sg_daemon to perform some tasks (and after the tasks are finished) the client does not end.
I corrected a lot of thoses problems.
A good example of this issue is with the
If sg_daemon supports XML and Base64 backends, and if the slack-get client supports XML and Gzip backends ; they will both agree on using the biggest common denominator (in this case they will use XML only).
I am very happy (and quite proud) of this mechanism. It allows tons of new development and many plugins to come !
As a conclusion, I will just say that there is still some works to do but it's becomming to be a very usable tool. I'm using it every day now.
I hope all the work I made on slack-get will be of interets for you all !
As a bonus track I give you the new slack-get logo (that I made myself... so be kind
)
Enjoy !
Arnaud Dupuis
There is a lot of new things that I need to talk about !
First the bad news : I saw on CPAN reports that the "fix" I made for Slackware::Slackget to properly test on Solaris OS is not working.
That is a bad thing but... I don't really see the purpose on trying to fix an issue on an OS which is not a Slackware based one and not even a GNU/Linux OS ! The Slackware::Slackget module will never be usefull on this OS, so since I have no Solaris to test I will just forget about it (unless somebody provides me with a patch for this system.
Now for all the good news :
- slack-get suite (sg_daemon + slack-get) is now able to install, upgrade and remove packages
So from now on, you can start a daemon and do a
"slack-get install
flightgear" for example That's a very important point but it's nothing worth talking about without the dependencies tracking system.
Talking about that...
- the dependencies tracking system is now fully functionnal
This part still need to be tested and there is no guarantees, so far, that it is working properly in all cases.
But so far my tests where very promisefull ! I add no problems and for the moment I have not yet discovered any bugs in this feature.
Again, that does not means that I will not uncover bugs later.
- add support for automatic GPG key import
This feature works well and is totally automatic : if sg_daemon do not find the Slackware Project's key in the user's GPG keyring, it download it and import it. Nice and easy.
- add new feature to slack-get (cli client)
"info". You can
use it the exact same way than the "search" command (this is the
exact same code which is processing it).The goal of this command is to provide more informations about a package. Here is an usage example :
$ ./slack-get info flightgear --media=slacky
Package: flightgear-1.0.0-i686-1as
Size (compressed): 3158 KB
Version: 1.0.0
Source: slacky
Description: The FlightGear flight simulator open-source project.The
goal of the FlightGear project is to create a
sophisticated flight simulator framework for use in
research or academic environments, for the development and
pursuit
of other interesting flight simulation ideas, and as an end-user
application
http://www.flightgear.org/ WWW.SLACKY.IT PackaGer Gohanz.This little example, allow me to introduce the new command line option : --media. This one allow you to restrict the "search" or "info" commandes to the choosen media (in the previous example I wanted only results from the Slacky.it website).
Last about the slack-get cli client, I fixed lots of "non closing bugs". The non closing bugs are an annoying problem of slack-get cli client.
While the whole system became multitasks, it's becomming difficult to keep track of what the client asked by itself (particularly in a multi-administrators context), and after asking a sg_daemon to perform some tasks (and after the tasks are finished) the client does not end.
I corrected a lot of thoses problems.
A good example of this issue is with the
"slack-get update"
command. This one scheduled a tasks to upgrade all packages which have new ones
in the patches/ subtree of the official-media (see config.xml). After the
update, the client was not quitting. It is now corrected.- dynamic network backends negociation
If sg_daemon supports XML and Base64 backends, and if the slack-get client supports XML and Gzip backends ; they will both agree on using the biggest common denominator (in this case they will use XML only).
I am very happy (and quite proud) of this mechanism. It allows tons of new development and many plugins to come !
- lots of updates in the Slackware::Slackget Perl module
As a conclusion, I will just say that there is still some works to do but it's becomming to be a very usable tool. I'm using it every day now.
I hope all the work I made on slack-get will be of interets for you all !
As a bonus track I give you the new slack-get logo (that I made myself... so be kind
)
Enjoy !
Arnaud Dupuis
Tuesday 1 January 2008
slack-get development diary #5
By Arnaud Dupuis on Tuesday 1 January 2008, 09:56 - slack-get development diary
Hi !
First of everything : I wish you all an happy new year. May all your desires come to reality !My own desire is to release a first version of the new slack-get daemon quickly as possible. I'm coding the real work for the upgrade and install actions (update, remove, search and the others are already working but the remove one was still not test on a real case).
Some things actually happened on slack-get development since the last diary.
Bugfixes
I fix a lots of (very old) bugs. For example, in the Slackware::Slackget::Base class (which is untouched since months), there was a bug and the FILELIST: tag from the packages text file was not removed correctly and was still present in the XML. This is now fixed.I also improve a lot the way metadata are parsed by classes like Slackware::Slackget::Package by simplifying the parsing regular expressions.
Without turning this diary in a bugfixe list, I also modify some XML parsing behaviors in order to make the resulting data structure consistent over time. I modified the Slackware::Slackget::Package class quite a lot and it now parse itself the dependency fields in the packages metadata and translates them into XML. The impact of this is : a bigger XML file (packages.xml), and an increased loading time. But in the other end, all data are now completely parsed in the XML file and there is no extra work to do after parsing, and the dependency tracking is a lot easier (and actually quicker ^^).
Remaining bugs
There is still a bug in Slackware::Slackget::Network::Backend::Gzip. The backend which is in charge to compress and uncompress the network messages... Well it's not working at all, and worst i don't know why. But in the other hand, i have not tried a lot to fix this module. I focus on sg_daemon and slack-get for the moment (and the involved vital modules).The Base64 and XML backends are still working fine.
Other stuff
You should also be aware that I'm trying to help as much as I can for the KDE 4.0 release, so until the 11th of January the slack-get's development will certainly be slowed down by my involvement in KDE 4.0 development.And on the 11th of January i'm going to snowboarding in the Alps until the 20th of January ! So I will not be available at all during this time... Off course, because I'll be too busy trying to break some of my bones
Wednesday 19 December 2007
"slack-get update" command on the way !
By Arnaud Dupuis on Wednesday 19 December 2007, 07:26 - slack-get
Hi,
Just to keep you up-to-date, the "slack-get remove <packages list>" command now works correctly (although I still need to do tons of testing) and the "slack-get update" command is on the good way.
Once it will be finished, the "slack-get upgrade <packages list>" will also be ready because both of those commands are closely bounded.
The difference between the two commands is pretty simple :
while the "upgrade" one allow you to upgrade (download + upgradepkg) a named list of packages, the "update" command check for all updates available in <repository root>/patches/packages/.
On a freshly installed Slackware 12.0 you get the following output (click on the image to enlarge it) :
That's all for today. See you later for the development diary.
Arnaud Dupuis.
Just to keep you up-to-date, the "slack-get remove <packages list>" command now works correctly (although I still need to do tons of testing) and the "slack-get update" command is on the good way.
Once it will be finished, the "slack-get upgrade <packages list>" will also be ready because both of those commands are closely bounded.
The difference between the two commands is pretty simple :
while the "upgrade" one allow you to upgrade (download + upgradepkg) a named list of packages, the "update" command check for all updates available in <repository root>/patches/packages/.
On a freshly installed Slackware 12.0 you get the following output (click on the image to enlarge it) :
That's all for today. See you later for the development diary.
Arnaud Dupuis.
Monday 10 December 2007
slack-get development diary #4
By Arnaud Dupuis on Monday 10 December 2007, 22:00 - slack-get development diary
Hi,
There is a lot to say for this development diary #4 !
If some of you still wondered : slackget10 is officially abandoned, and today, completely outdated.
I added a lot of features to this module like the stackable backends. I also released on CPAN a debug module which add the support for a debug:// network protocol. This is a totally fake protocol which help development by outputing loads of informations on the standard output. The module name is Slackware::Slackget::Network::Connection::DEBUG. It's not a part of the Slackware::Slackget distribution, it's even not in the SVN trunk but in branch/perl-modules.
One of the big improvement of the Slackware::Slackget module is its test suite : the latest release on CPAN (0.14) haven't encounter even 1 fail !
I also tried a lot to make the module platform independent, and more generic. I have rewrite lots of code in order to take all the interdependent code out of the modules. It's now partially done and the next module which will feel my scalpel is Slackware::Slackget::PkgTools... I saw some horrible things inside of this one !
Let's show you some search request performed on a cache which contains the official Slackware current repository, Linuxpackages repository and my own perl-modules repository (totally outdated) :
This is a big improvement since it actually do something... You may wonder how it is possible for me to implements 3 or 4 possible actions (features) for slack-get and have wait for so long before doing it. In fact it's now very easy and quick to add features to sg_daemon and slack-get because the base architecture is done coding (and well designed :D).
From now on, the remaining features I will include before releasing a first version (without any GUI but with the CLI client) are :
In the real coding side, the last SVN revision of sg_daemon include tons of improvements like : automatic message formating, a first version of the backend stack negotiation system (between the daemon and the client), a real and simple network protocol, a powerfull and working base architecture and a bullet proof internal communication ! (with that if I don't attract some geek devs I don't know how to do it ).
The next big part of the work will be the implementation of collaborative part. But fortunately, a huge amount of this code was already wrote in slack-get-1.0.0-alpha1. To give you an example, all the code related to the master/slave mechanism is already written and slack-getd is able to work with many other daemons withtout to much pain in the configuration side (assuming you talk XML...).
But in addition to the existing code (that I will still need to port to the new event-based architecture), I want to add an "auto discover" feature to allow many sg_daemon(s) to work together without any configuration or human supervision. I want the daemons able to elect a master, change their mode between master and slave, and many other distributed stuffs like that, based on some simple rules (what's the sysload, the average sysload, etc.) in total autonomy (if the sysadmin allow it !).
In addition to all of this development, I will publish a debug backend for Slackware::Slackget::Network to allow developers to track the state of a network message during the encoding and decoding process.
And since it's the first screenshot I can show, here it is :
Well... nothing to climb to the roof but it's a beginning
All the testing GUI are available from the SVN branch : branch/gui_test.
The GUI is the next main development priority after getting the daemon working.
I think I'm done with this week (and a half...) diary, I'll keep you informed !
Cya
Arnaud Dupuis.
There is a lot to say for this development diary #4 !
Perl module: Slackware::Slackget vs slackget10 :
First of all, the Perl part of the project (currently the biggest part). As you may all know now : the slack-get Perl module is now listed in the official Perl Module list on CPAN in the Operating System Interface category. And for this big promotion the module changed its name from slackget10 to Slackware::Slackget.If some of you still wondered : slackget10 is officially abandoned, and today, completely outdated.
I added a lot of features to this module like the stackable backends. I also released on CPAN a debug module which add the support for a debug:// network protocol. This is a totally fake protocol which help development by outputing loads of informations on the standard output. The module name is Slackware::Slackget::Network::Connection::DEBUG. It's not a part of the Slackware::Slackget distribution, it's even not in the SVN trunk but in branch/perl-modules.
One of the big improvement of the Slackware::Slackget module is its test suite : the latest release on CPAN (0.14) haven't encounter even 1 fail !
I also tried a lot to make the module platform independent, and more generic. I have rewrite lots of code in order to take all the interdependent code out of the modules. It's now partially done and the next module which will feel my scalpel is Slackware::Slackget::PkgTools... I saw some horrible things inside of this one !
The slack-get suite programs : sg_daemon and slack-get :
Everything have changed ! Beginning with slack-get : this program wasn't available 2 weeks ago. It's a command line client for the sg_daemon it allow you to query the daemon. At the moment I write this development diary (svn revision 110) you can perform the following actions with slack-get : search a package (based on it's name, or anything in the description of this package), ask the daemon to rebuild the installed packages cache, ask the daemon to reload it's media list, ask the daemon to rebuild the update list. Well... now it only lack the possibility to install, upgrade and remove packages to be released... I'm already on the remove part (the easiest ^^).Let's show you some search request performed on a cache which contains the official Slackware current repository, Linuxpackages repository and my own perl-modules repository (totally outdated) :
This is a big improvement since it actually do something... You may wonder how it is possible for me to implements 3 or 4 possible actions (features) for slack-get and have wait for so long before doing it. In fact it's now very easy and quick to add features to sg_daemon and slack-get because the base architecture is done coding (and well designed :D).
From now on, the remaining features I will include before releasing a first version (without any GUI but with the CLI client) are :
- install package
- upgrade package
- remove package
- run background for the daemon
In the real coding side, the last SVN revision of sg_daemon include tons of improvements like : automatic message formating, a first version of the backend stack negotiation system (between the daemon and the client), a real and simple network protocol, a powerfull and working base architecture and a bullet proof internal communication ! (with that if I don't attract some geek devs I don't know how to do it
).The next big part of the work will be the implementation of collaborative part. But fortunately, a huge amount of this code was already wrote in slack-get-1.0.0-alpha1. To give you an example, all the code related to the master/slave mechanism is already written and slack-getd is able to work with many other daemons withtout to much pain in the configuration side (assuming you talk XML...).
But in addition to the existing code (that I will still need to port to the new event-based architecture), I want to add an "auto discover" feature to allow many sg_daemon(s) to work together without any configuration or human supervision. I want the daemons able to elect a master, change their mode between master and slave, and many other distributed stuffs like that, based on some simple rules (what's the sysload, the average sysload, etc.) in total autonomy (if the sysadmin allow it !).
In addition to all of this development, I will publish a debug backend for Slackware::Slackget::Network to allow developers to track the state of a network message during the encoding and decoding process.
Some news from the GUI point :
I made a graphical interface to get the list of official Slackware mirrors (from the "Get Slack" page of the official website). It's still not finished (it cannot update the medias.xml file yet), but it's already working to get the list and writting it down to the hard disk. I think this dialog will be part of the final slack-get GUI.And since it's the first screenshot I can show, here it is :
Well... nothing to climb to the roof but it's a beginning
All the testing GUI are available from the SVN branch : branch/gui_test.
The GUI is the next main development priority after getting the daemon working.
I think I'm done with this week (and a half...) diary, I'll keep you informed !
Cya
Arnaud Dupuis.
