Re: [Mageia-dev] [Cooker] [RFC] Ruby packaging policy
2011/1/7 Remy CLOUARD :
> Hello there,
>
> It’s been quite some time since I started working on ruby modules, and
> I’ve been working on the policy too.
\o/
>
> You can find the page here:
> http://wiki.mandriva.com/en/Policies/Ruby
>
> Now, there are some things that still need to be clarified.
>
> The most controversial part is the naming convention.
>
> Many ruby modules are packaged via gem, and fedora introduced a strange
> naming convention, calling their package rubygem-%{gemname}. This
> convention was soon followed by other rpm-based distro such as opensuse
> and momonga, and we also have some of them.
I adopted the rubygem-* naming convention for ruby gems due to the
different way of it being installed opposed to installing it as a
ehr.. non-gem.. (ie. ruby-foo & rubygem-foo would come with the same
ruby module, but installed & packaged differently), to provide a
distinct namespace with less confusion (ie. there seems to be some
conventions on naming ruby modules as ie. 'ruby-foo' for the pure ruby
implementation of 'foo' which might've been written in C etc., always
using the namespace 'rubygem' giving the resulting rubygem-ruby-foo &
rubygem-foo packages) and for the general ease on maintenace by
adopting existing layouts already chosen by other distributions..
>
> I’m not against changing that convention, but this raises also other
> questions.
> 1) Do we also need to change the provides/requires ? ie
No, whatever package filenames chosen, it's really a different topic
than whatever
provides/required that should be generated.
Using rubygem() provides though (yet again) a distinct namespace for these
dependencies automatically generated from the gem metadata, so to ensure these
remaining canonical and without ambiguity, they shouldn't be changed.
Notice that the dependency extractor used is the same one used for
rpm5 upstream,
so by making such changes you'd also end up breaking compatibility
with it as well.
> Requires: ruby(%{gemname})
> instead of
> Requires: rubygem(%{gemname})
> 2) is there a way to make youri watch for rubygem-%{gemname} in case we
> opt for that change ? Or better, can youri watch for %{gemname} on
> rubygems.org ?
provides/requires of ruby gems are already automatically generated to
use rubygem(%{gemname}), so no need to add any explicit provides to
packages and for non-gems where you'd need to add explicit requires on
gems, you should add rubygem(%{gemname}).
>
> Is it ok to add development dependencies as Suggests ? Shall we do a
> -devel subpackage that will pull these dependencies. The advantage of
> doing this is that automated installs will not add these dependencies
> where they aren’t needed, but this will cause spec files to be more
> complicated to maintain (unless we add proper support for this in
> gem2rpm)
Currently it's trivial to add support for generating suggests on these
automatically,
but it's usually not really what's desired with the default behaviour
(with urpmi) of installing
suggests automatically.
Adding support for gem2rpm for creating a meta subpackage would be
trivial, but then you would
have to manually maintain explicit provides/requires for these in the
spec, in contrast to
those automatically generated by rpm during build.
A meta subpackage sounds fairly reasonable (given the current
alternatives rpm provides,
I'm not opposed to implementing something better), but should really be
generated automatically in same fashion from the gem metadata during
build, and not
during initial package creation to be maintained manually afterwards,
but there's no
standard convention for automatically generating sub-packages in place
to use yet.
So if you want support for making use of this metadata in some
sensible and easily maintanable
way, some extra work will be required, as it would fall on rpm's
responsibility to
automatically do so and without extra mess to maintain in packages, I
would advice to
leave it out of packaging policies dictated for packagers to worry
about, rather proposing
it as a feature request for rpm.
>
> About files:
> shall we keep the gem in the cache directory ? I’m not sure this is
> really useful, up till now I added it, but it makes the package a bit
> bigger
Nah, there's no use for it, that's why I implemented gem_helper.rb
(which is what the %gem_build
& %gem_install macros are wrapped around) to drop it by default.
Also notice that gem_helper.rb will also actually recreate the gem
with all the files
that's not of any use dropped, then install this gem.
I *think* the behaviour should be pretty sane and generic enough to
work with most gems
(to my understanding of gem packaging at least;), although the code
itself isn't all that pretty
(some of the very first ruby code I wrote a year ago) and certainly
wouldn't hurt from
being given some care and cleaned up by someone with better ruby
skills and nicer ruby dialect
than mine.. ;)
>
> Shall we do a -doc subpackage for big packages ? I think it may be
> interesting for packa
[Mageia-dev] News of the front: first commits and mentoring start
Hi there As planned in our last meeting, work has started with about 40 packagers who had already packager account in Mandriva Linux. They are at the moment creating their account, getting right access and importing first packages. In same time submit process of packages is nearly done and tests are in progress. Base system packages are getting submitted in tree. In same time we will start mentoring on people who said to be already familiar with packaging so that they can join packagers team as soon as possible, mainly Blograke and mandrivausers.de packagers. Below are lists of mentors and trainees. Please have a look on it and ask for mentor to start process. Mentors === Anssi Hannula (Anssi) - anssi.hann...@iki.fi - Can mentor several people Jérôme Quelin (jquelin) - jque...@gmail.com - can mentor several people Rémy CLOUARD (shikamaru) - shikam...@shikamaru.fr - Can mentor one person at a time Philippe Makowski (philippeM) - makowski.mag...@gmail.com - Can mentor one person at a time John Balcaen (mikala) - balcaen.j...@gmail.com - Can mentor one persone at a time Trainees Annubis tomasdeltell AT gmx DOT es Tomàs Deltell art_bender bartben...@gmail.comJose Fernández Rosa Bersuit bersuit.vera AT gmail DOT comAlfonso Vera bertux b at juglas point name Bertrand Juglas deapdpernot!at!gmail[dot]com David Pernot doktor5000 doktor5000 AT arcor DOT de Florian Hubold dorileo ldorileo [at] gmail.com Leandro Dorileo drivael rafael at drivael dot comRafael Drivael gejogejobj AT gmail DOT com Gerardo Bueno GregoryBravasgigartua AT gmail DOT com Gonzalo Igartua jhenin heninj~gmail Jérôme Hénin legner legnerquero [AT] gmail [DOT] com Egner Quero obgr_seneca oliver.bgr AT googlemail DOT comOliver Burger pernnp ercy dot lau at gmail dot comLiuPeng tombhadACtombhadAC [at] haibox [dot] net Daniel Wünsch VaCi0 cvargas [at] linuxmail [dot] org César Vargas venbea juan[dot]gamez[at]gmail[dot]com Juan Gamez Cheers -- Anne http://www.mageia.org
[Mageia-dev] [RFC] Ruby packaging policy
Hello there,
It’s been quite some time since I started working on ruby modules, and
I’ve been working on the policy too.
You can find the page here:
http://wiki.mandriva.com/en/Policies/Ruby
Now, there are some things that still need to be clarified.
The most controversial part is the naming convention.
Many ruby modules are packaged via gem, and fedora introduced a strange
naming convention, calling their package rubygem-%{gemname}. This
convention was soon followed by other rpm-based distro such as opensuse
and momonga, and we also have some of them.
I’m not against changing that convention, but this raises also other
questions.
1) Do we also need to change the provides/requires ? ie
Requires: ruby(%{gemname})
instead of
Requires: rubygem(%{gemname})
2) is there a way to make youri watch for rubygem-%{gemname} in case we
opt for that change ? Or better, can youri watch for %{gemname} on
rubygems.org ?
Is it ok to add development dependencies as Suggests ? Shall we do a
-devel subpackage that will pull these dependencies. The advantage of
doing this is that automated installs will not add these dependencies
where they aren’t needed, but this will cause spec files to be more
complicated to maintain (unless we add proper support for this in
gem2rpm)
About files:
shall we keep the gem in the cache directory ? I’m not sure this is
really useful, up till now I added it, but it makes the package a bit
bigger
Shall we do a -doc subpackage for big packages ? I think it may be
interesting for package that have a lot of documentation and that are
part of an ecosystem (ie, gems required for other packages like
gitorious)
Normally %gem_* macros should take care of that, but we might have to
make it evolve.
Do you see something I haven’t thought of ?
I will provide an example spec in this policy in the following days, and
will take care of making the necessary changes to the existing packages
once we agree with the above points.
Thanks in advance,
Best regards,
--
Rémy CLOUARD
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
pgpl6a8SbXovl.pgp
Description: PGP signature
Re: [Mageia-dev] Mageia policies
Hi guys, First of all, thanks for the reviews ! Huge kudos to Daniel who reviewed most of them. But, as you may probably know, the mentoring process will begin pretty soon. That’s why we need to review the remaining policies in the following days. Here is a page listing all policies and their current status: http://mageia.org/wiki/doku.php?id=policies-review We need help from experienced packagers to achieve that, some policies need proofreading, other have to be started. To start with, I’ll do my part on the ruby packaging policy. This policy is still a draft, and I will send a mail to both mandriva-cooker and mageia-dev. Now, let’s take http://mageia.org/wiki/doku.php?id=packaging#main_packages_by_category as a base to assign the review to people. I know tmb is quite busy with setting up the basesystem, so I wonder if he could review the kernel policies, perhaps Anssi can take the DKMS part ? It would be nice if perl gurus review the perl packaging policies (jq, guillomovitch, nanar) The python policy is a bit of a draft too, but it would be nice if it could be completed so that it is included (misc, philippeM) As for the other languages, haskell and ocaml policies are quite complete and could be included, but at the moment we also need people volunteering to maintain these packages (as far as I’m concerned, my only haskell package is xmonad, and I will be quite busy with ruby modules. I guess many people would be able to review the other policies. I would be glad if we could have policies reviewed quite quickly. Thanks in advance, Regards, -- Rémy CLOUARD () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments pgpM1MbQ3c1Mh.pgp Description: PGP signature
Re: [Mageia-dev] New bugzilla proposal
On Fri, Jan 7, 2011 at 19:04, Romain d'Alverny wrote: > * Mageia with components: > - installation > - software + RPM package > - new software request replace with new RPM package request > - release (media, process) > - (for versions, cauldron first, we'll see later for the rest) And or maybe have the "software" component brought up as a separate Product, actually (would make even more sense), with the list of actual software involved. Romain
Re: [Mageia-dev] New bugzilla proposal
Ok, the point of this discussion is to know what we put as: - Products - Components This can be updated later (as in: adding/renaming products/components). So we should just aim at the smallest acceptable set, so that we can open our Bugzilla instance, see what it shows, update and open it for actual usage. So trying to summarize above discussion, I suggest as products: * Mageia with components: - installation - software - new software request - release (media, process) - (for versions, cauldron first, we'll see later for the rest) * Websites with components: - www - forum - blog - wiki - maint-db - (for versions, live/dev does not make much sense here; so maybe just numbering, maybe just no version for a start; depends on the release process) * Infrastructure - ? (misc?) If that's ok (or if we can make it smaller so that it's working), we can move forward and set this up finally (modulo the rpm field setup, but that's not blocking for once). Cheers, Romain
Re: [Mageia-dev] New bugzilla proposal
On Fri, Jan 7, 2011 at 17:49, andre999 wrote: > > Frederic Janssens a écrit : > >> >> On Fri, Jan 7, 2011 at 06:19, andre999 wrote: >>> >>> >>> As for documentation and translations, a while back I suggested a similar >>> separation, but on reflection I think it would be more useful to have flags >>> : >>> >>> 1) problem with documentation (and not function) >>> These bugs would be best corrected by those with good documentation skills, >>> not necessarily the average programmmer. >>> >>> 2) problem with translation (and not function) >>> These bugs would be best corrected by technical translators for the >>> language in question. Again, not necessarily the average programmer. >>> >> >> I am working on a script intended to make it easyer to report bugs usefully. >> >> Technically, would these flags be new fields, >> or standardized entries in the Keywords field, >> such as NEEDINFO in the present Mandriva bugzilla ? > > > Just verified with bugzilla to make sure. > > Documentation and translations are listed as options under "components". > However any such bug could also be associated with another component, such as > "core packages" or "release media". > We could even have translation bugs of documentation. > > So it would seem better if these were independant flags, instead of options. > It that case they would be new fields. > > As for security, there are already 2 such flags, at the bottom of the main > bug entry page. (Under the title "privacy".) > Checking either of these flags will cause a bug to be hidden from most users, > as explained beside the check boxes. > (For this reason, it would be better to _not_ duplicate these particular > flags elsewhere.) > > see https://qa.mandriva.com/enter_bug.cgi?product=Mandriva Linux&format=guided The potential problem with new fields, which would be better, would be to make shure that they are accessible with the xmlrpc interface, that I use for my script. The inbuilt Keywords field, which does not appear on the Mandriva 'guided' input page, but does appear on the 'expert' input page, is accessible with the xmlrpc interface. The xmlrpc interface does not seem to automatically have access to all fields. But it is difficult to be shure : the xmlrpc interface of Mandriva bugzilla does not work; and the Mageia bugzilla only has the default fields at present. I think I will have to create a local bugzilla to test that. > Good luck with your script :) Thanks > André -- Frederic
Re: [Mageia-dev] New bugzilla proposal
Michael Scherer a écrit : Le jeudi 06 janvier 2011 à 18:43 +0100, Wolfgang Bornath a écrit : 2011/1/6 Michael Scherer: And for the rest, well, the bug be it in documentation, translation, or code must follow the same lifecycle, and imho, should be grouper logically and we should not duplicate information everywhere, with information being "version of the product/components". How would you group a translation error in the documentation of rpmdrake? How would you group a documentation error in teh documentation of rpmdrake How would you group a translation error in rpmdrake? The question before "how" is "why". Why would you want to group all documentation error together ? Grouping by "product" ( not in the bugzilla meaning ) is IMHO required to avoid duplication of version, to be able to see what bugs affect a precise version of a software, be it a documentation bug, translation bug and so on, and so decide if a software is ready for release. Good point. Mandriva bugzilla currently includes documentation and translations as options in the "components" field. It would be much better to have them as flags, independant of components, as each could apply to other components. (We even have translations of documentation.) This would facilitate searches for those who wish to identify (and correct) documentation or translation errors, and help ensure that such bugs are identified as such. (Instead of being identified by the actuel component.) Thus adding documentation and translation flags, and removing them as options of components. And, as you suggest, keep grouping by the product, instead of the type of bug. my 2 cents :)
Re: [Mageia-dev] New bugzilla proposal
Frederic Janssens a écrit : On Fri, Jan 7, 2011 at 06:19, andre999 wrote: As for documentation and translations, a while back I suggested a similar separation, but on reflection I think it would be more useful to have flags : 1) problem with documentation (and not function) These bugs would be best corrected by those with good documentation skills, not necessarily the average programmmer. 2) problem with translation (and not function) These bugs would be best corrected by technical translators for the language in question. Again, not necessarily the average programmer. One or both could be checked for any particular bug. Thus facilitating a search for bugs based on these flags. Those wanting to ignore such bugs could equally avoid seeing them. This would tend to facilitate the correction of such bugs, which tend to be lost and not corrected for long periods of time. (At least that is the case with Mandriva, and much other free/open source software.) (e.g.1: A number of French translations.) (e.g.2: Much documentation is essentially useless to the uninitiated.) However, in my view, documentation and translation bugs would also tend to be reported by different people than those who would report function bugs. So it would be useful if such flags were to appear on this initial page, as well on the main bug entry page. Something like "This bug concerns [ ]documentation ... [ ]translation ..." With whatever other factors, such as security, on which we decide to focus. With whatever boxes are checked carried over automatically to the main bug entry page. I am working on a script intended to make it easyer to report bugs usefully. Technically, would these flags be new fields, or standardized entries in the Keywords field, such as NEEDINFO in the present Mandriva bugzilla ? Just verified with bugzilla to make sure. Documentation and translations are listed as options under "components". However any such bug could also be associated with another component, such as "core packages" or "release media". We could even have translation bugs of documentation. So it would seem better if these were independant flags, instead of options. It that case they would be new fields. As for security, there are already 2 such flags, at the bottom of the main bug entry page. (Under the title "privacy".) Checking either of these flags will cause a bug to be hidden from most users, as explained beside the check boxes. (For this reason, it would be better to _not_ duplicate these particular flags elsewhere.) see https://qa.mandriva.com/enter_bug.cgi?product=Mandriva Linux&format=guided Good luck with your script :) André
Re: [Mageia-dev] New bugzilla proposal
On Fri, Jan 7, 2011 at 06:19, andre999 wrote: > > > As for documentation and translations, a while back I suggested a similar > separation, but on reflection I think it would be more useful to have flags : > > 1) problem with documentation (and not function) > These bugs would be best corrected by those with good documentation skills, > not necessarily the average programmmer. > > 2) problem with translation (and not function) > These bugs would be best corrected by technical translators for the language > in question. Again, not necessarily the average programmer. > > One or both could be checked for any particular bug. > Thus facilitating a search for bugs based on these flags. > Those wanting to ignore such bugs could equally avoid seeing them. > > This would tend to facilitate the correction of such bugs, which tend to be > lost and not corrected for long periods of time. (At least that is the case > with Mandriva, and much other free/open source software.) > (e.g.1: A number of French translations.) > (e.g.2: Much documentation is essentially useless to the uninitiated.) > > However, in my view, documentation and translation bugs would also tend to be > reported by different people than those who would report function bugs. > So it would be useful if such flags were to appear on this initial page, as > well on the main bug entry page. > Something like > "This bug concerns [ ]documentation ... [ ]translation ..." > With whatever other factors, such as security, on which we decide to focus. > With whatever boxes are checked carried over automatically to the main bug > entry page. I am working on a script intended to make it easyer to report bugs usefully. Technically, would these flags be new fields, or standardized entries in the Keywords field, such as NEEDINFO in the present Mandriva bugzilla ? > > another 2 cents :) > > André -- Frederic
Re: [Mageia-dev] Adding Java-Policy
As the actual policy is too old, who wants to write a new one describing the open jdk instead of gcj ? My experience in packaging is not too good to do that on my own. -- Mit freundlichen Grüßen Greetings Daniel Kreuter
