Re: [Mageia-dev] announcing magpie
On 11/02/02 16:33 +0100, nicolas vigier wrote: Hm, for such seemingly trivial feature additions, wouldn't it make more sense to just implement it in repsys..? Jerome makes his scripts in perl. And mgarepo is in python. So it makes sense to distribute it separatly. And some of the features can still be implemented later in mgarepo if it appears they are useful to a lot of people ... more importantly, those trivial features are designed to be coupled later on. and this will be much easier to do if every action is available in a module of its own... eg, here are some other scripts that i have, intend to clean port to magpie subcommands: - update a perl module to latest version without having to specify said version. i already have sthg that works (for more than 2 years), which means that to update a pkg in mandriva i used to do: $ cooker perl-Foo-Bar refresh (cooker command was the equivalent of magpie co) - list all perl modules needing to be updated, grouped by core, dual-lifed or regular modules. i used to do the following to know which modules to update: $ cpan-old - order a group of packages to be rebuilt according to their build requires. this allowed me to rebuild ~2400 perl packages for mageia quite easily. now, the grand plan for magpie is to integrate all those commands then to create a new subcommand that would automatically: - run cpan-old (magpie xxx to be created) - sort them according to their buildrequires (magpie xxx to be created) - for each of them, check it out (magpie co) - get latest version, update, build submit (magpie xxx to be created) - wait a bit if needed (magpie bswait) - go back to step 2 now, you do understand that even if perl allows me to seemlessly call various scripts written in whatever language (bash, python, etc), having all subcommands sanitized and available as module will make all the plumbing much more efficient, clean maintainable. oh - another thing. had i decided not to clean my collection of scripts and publish them as a perl module, those scripts would still sit on my computer and would not be shared. and i definitely think that it's a good thing to share: it will allow people to help maintain perl packages (and thus reducing my workload), not counting the fact that it may be useful for other distributions too (*cough* mandriva *cough*). hoping to clarify the rationale of magpie, jérôme -- jque...@gmail.com
Re: [Mageia-dev] Packager meetings for tonight
Le mercredi 02 février 2011 à 17:26 +0100, Michael Scherer a écrit : Hi, Next meeting will happen tonight on #mageia-dev at 20h UTC. Quick proposal for agenda ( the meeting must be quick ) : - review of the task distributed last week ( http://meetbot.mageia.org/mageia-dev/2011/mageia-dev.2011-01-26-20.03.html ) - proposal on what should be imported in priority ( and distribution of the work ) So as discussed tonight ( but if you couldn't be present at the meeting, do not hesitate to express yourself now ), we proposed to have some order in the import of rpm ( ie avoid the resulting anarchy due to lack of process for bootstrap ). In order to start by something tangible and easy to manage, let's take a concrete case. The sysadmin team discussed to use mageia on the servers ( once the stable release is out ie, not now ) for obvious reasons of dogfooding. But for this, we will have to import the needed rpms. I extracted from puppet logs the lists of rpm, and I have a list of the major component needed. The rule would be to take 1 and only 1 rpm ( or family ) at the time, to make sure it work fine ( ie, compile for the moment, and also install ), to make sure the package is cleaned ( ie, patchs sent upstream, commented, etc ), and to make sure that everybody can find something to do. And that of course requires to do the same for missing BuildRequires, and Requires ( but since lots of rpm have been imported without being fully cleaned, and since there is now a fast web interface for svn, people have no excuse to not check ). I will place the list on the wiki tomorrow, and people wishing to work on importing a rpm should add their name/login/whatever after the rpm, and then to work on it. If there is already someone working on a rpm, just take another one, or try to work with this person. Of course, nothing prevent people from working on something else if they wish, but this list of package are IMHO the one that we are sure to find testers ( aka sysadmins ). Moreover, as most if not all are servers, or at least, stuff without graphical interface, they will be ready to be tested once the mirror will be ready. Once this list wil be cleared, we will likely be ready on more consequent bunch of rpms ( like kde, gnome, xfce, etc, etc ). So if someone has remarks, or questions, do not hesitate. -- Michael Scherer
