diff options
Diffstat (limited to 'zarb-ml/mageia-dev/20110108/002011.html')
| -rw-r--r-- | zarb-ml/mageia-dev/20110108/002011.html | 230 |
1 files changed, 230 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20110108/002011.html b/zarb-ml/mageia-dev/20110108/002011.html new file mode 100644 index 000000000..a7b0c0d3e --- /dev/null +++ b/zarb-ml/mageia-dev/20110108/002011.html @@ -0,0 +1,230 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] [Cooker] [RFC] Ruby packaging policy + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20%5BCooker%5D%20%5BRFC%5D%20Ruby%20packaging%20policy&In-Reply-To=%3C20110108100217.GC3471%40shikamaru.fr%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="002009.html"> + <LINK REL="Next" HREF="002010.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] [Cooker] [RFC] Ruby packaging policy</H1> + <B>Remy CLOUARD</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20%5BCooker%5D%20%5BRFC%5D%20Ruby%20packaging%20policy&In-Reply-To=%3C20110108100217.GC3471%40shikamaru.fr%3E" + TITLE="[Mageia-dev] [Cooker] [RFC] Ruby packaging policy">shikamaru at mandriva.org + </A><BR> + <I>Sat Jan 8 11:02:17 CET 2011</I> + <P><UL> + <LI>Previous message: <A HREF="002009.html">[Mageia-dev] [Cooker] [RFC] Ruby packaging policy +</A></li> + <LI>Next message: <A HREF="002010.html">[Mageia-dev] Adding Java-Policy +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#2011">[ date ]</a> + <a href="thread.html#2011">[ thread ]</a> + <a href="subject.html#2011">[ subject ]</a> + <a href="author.html#2011">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>On Sat, Jan 08, 2011 at 05:07:55AM +0100, Per Øyvind Karlsen wrote: +><i> 2011/1/7 Remy CLOUARD <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">shikamaru at mandriva.org</A>>: +</I>><i> > Hello there, +</I>><i> > +</I>><i> > It’s been quite some time since I started working on ruby modules, and +</I>><i> > I’ve been working on the policy too. +</I>><i> \o/ +</I>First of all, thanks for your very complete answer. :) +><i> > +</I>><i> > You can find the page here: +</I>><i> > <A HREF="http://wiki.mandriva.com/en/Policies/Ruby">http://wiki.mandriva.com/en/Policies/Ruby</A> +</I>><i> > +</I>><i> > Now, there are some things that still need to be clarified. +</I>><i> > +</I>><i> > The most controversial part is the naming convention. +</I>><i> > +</I>><i> > Many ruby modules are packaged via gem, and fedora introduced a strange +</I>><i> > naming convention, calling their package rubygem-%{gemname}. This +</I>><i> > convention was soon followed by other rpm-based distro such as opensuse +</I>><i> > and momonga, and we also have some of them. +</I>><i> I adopted the rubygem-* naming convention for ruby gems due to the +</I>><i> different way of it being installed opposed to installing it as a +</I>><i> ehr.. non-gem.. (ie. ruby-foo & rubygem-foo would come with the same +</I>><i> ruby module, but installed & packaged differently), to provide a +</I>><i> distinct namespace with less confusion (ie. there seems to be some +</I>><i> conventions on naming ruby modules as ie. 'ruby-foo' for the pure ruby +</I>><i> implementation of 'foo' which might've been written in C etc., always +</I>><i> using the namespace 'rubygem' giving the resulting rubygem-ruby-foo & +</I>><i> rubygem-foo packages) and for the general ease on maintenace by +</I>><i> adopting existing layouts already chosen by other distributions.. +</I>><i> +</I>><i> +</I>That does make sense as long as we keep both kinds of packaging. But I’m +pretty sure there won’t be many breakages by switching to one kind of +packaging to another, thus it would make sense to have every ruby-foo +package use the gem system, and then, we could choose one or the other +naming scheme. +><i> > +</I>><i> > I’m not against changing that convention, but this raises also other +</I>><i> > questions. +</I>><i> > 1) Do we also need to change the provides/requires ? ie +</I>><i> No, whatever package filenames chosen, it's really a different topic +</I>><i> than whatever +</I>><i> provides/required that should be generated. +</I>><i> Using rubygem() provides though (yet again) a distinct namespace for these +</I>><i> dependencies automatically generated from the gem metadata, so to ensure these +</I>><i> remaining canonical and without ambiguity, they shouldn't be changed. +</I>><i> Notice that the dependency extractor used is the same one used for +</I>><i> rpm5 upstream, +</I>><i> so by making such changes you'd also end up breaking compatibility +</I>><i> with it as well. +</I>Well, nothing prevents us from suggesting that change upstream, I think +these changes might be discussed upstream too, but I agree that this +change will only bring little benefit, so I think this won’t change +><i> > Requires: ruby(%{gemname}) +</I>><i> > instead of +</I>><i> > Requires: rubygem(%{gemname}) +</I>><i> > 2) is there a way to make youri watch for rubygem-%{gemname} in case we +</I>><i> > opt for that change ? Or better, can youri watch for %{gemname} on +</I>><i> > rubygems.org ? +</I>><i> provides/requires of ruby gems are already automatically generated to +</I>><i> use rubygem(%{gemname}), so no need to add any explicit provides to +</I>><i> packages and for non-gems where you'd need to add explicit requires on +</I>><i> gems, you should add rubygem(%{gemname}). +</I>I think you misunderstood what I said there, I was thinking about +youri-check, see <A HREF="http://youri.zarb.org/demo/mandriva/">http://youri.zarb.org/demo/mandriva/</A> +><i> > +</I>><i> > Is it ok to add development dependencies as Suggests ? Shall we do a +</I>><i> > -devel subpackage that will pull these dependencies. The advantage of +</I>><i> > doing this is that automated installs will not add these dependencies +</I>><i> > where they aren’t needed, but this will cause spec files to be more +</I>><i> > complicated to maintain (unless we add proper support for this in +</I>><i> > gem2rpm) +</I>><i> Currently it's trivial to add support for generating suggests on these +</I>><i> automatically, +</I>><i> but it's usually not really what's desired with the default behaviour +</I>><i> (with urpmi) of installing +</I>><i> suggests automatically. +</I>><i> Adding support for gem2rpm for creating a meta subpackage would be +</I>><i> trivial, but then you would +</I>><i> have to manually maintain explicit provides/requires for these in the +</I>><i> spec, in contrast to +</I>><i> those automatically generated by rpm during build. +</I>><i> A meta subpackage sounds fairly reasonable (given the current +</I>><i> alternatives rpm provides, +</I>><i> I'm not opposed to implementing something better), but should really be +</I>><i> generated automatically in same fashion from the gem metadata during +</I>><i> build, and not +</I>><i> during initial package creation to be maintained manually afterwards, +</I>><i> but there's no +</I>><i> standard convention for automatically generating sub-packages in place +</I>><i> to use yet. +</I>><i> So if you want support for making use of this metadata in some +</I>><i> sensible and easily maintanable +</I>><i> way, some extra work will be required, as it would fall on rpm's +</I>><i> responsibility to +</I>><i> automatically do so and without extra mess to maintain in packages, I +</I>><i> would advice to +</I>><i> leave it out of packaging policies dictated for packagers to worry +</I>><i> about, rather proposing +</I>><i> it as a feature request for rpm. +</I>Likewise, can also be discussed upstream so. +><i> > +</I>><i> > About files: +</I>><i> > shall we keep the gem in the cache directory ? I’m not sure this is +</I>><i> > really useful, up till now I added it, but it makes the package a bit +</I>><i> > bigger +</I>><i> Nah, there's no use for it, that's why I implemented gem_helper.rb +</I>><i> (which is what the %gem_build +</I>><i> & %gem_install macros are wrapped around) to drop it by default. +</I>><i> Also notice that gem_helper.rb will also actually recreate the gem +</I>><i> with all the files +</I>><i> that's not of any use dropped, then install this gem. +</I>><i> I *think* the behaviour should be pretty sane and generic enough to +</I>><i> work with most gems +</I>><i> (to my understanding of gem packaging at least;), although the code +</I>><i> itself isn't all that pretty +</I>><i> (some of the very first ruby code I wrote a year ago) and certainly +</I>><i> wouldn't hurt from +</I>><i> being given some care and cleaned up by someone with better ruby +</I>><i> skills and nicer ruby dialect +</I>><i> than mine.. ;) +</I>><i> > +</I>><i> > Shall we do a -doc subpackage for big packages ? I think it may be +</I>><i> > interesting for package that have a lot of documentation and that are +</I>><i> > part of an ecosystem (ie, gems required for other packages like +</I>><i> > gitorious) +</I>><i> I certainly think -doc subpackages are of use, but from what to dictate any +</I>><i> conditionals where and when to create such is something I'm not 100% on (I've +</I>><i> added support to gem2rpm to do it for files specified as documentation by the +</I>><i> gem metadata though), nor on *how* (should it be done by gem2rpm, +</I>><i> or perhaps automatically during package build from the metadata, in +</I>><i> similar fashion +</I>><i> as proposed for -devel packages above?), I'm able to implement (or +</I>><i> provide help in +</I>><i> doing so) the request once the desired behaviour has been figured out though. ;) +</I>><i> > +</I>><i> > Normally %gem_* macros should take care of that, but we might have to +</I>><i> > make it evolve. +</I>><i> I think either way one should anyways try to keep as much as possible out of the +</I>><i> .spec files, leaving as much as possible up to macros, wrappers, dependency +</I>><i> extractors etc. to take care of. It'll help reduce maintenance work on +</I>><i> the individual +</I>><i> packages and help improve compatibility with other distributions. +</I>100% agree on this. +><i> > +</I>><i> > Do you see something I haven’t thought of ? +</I>><i> > +</I>><i> > I will provide an example spec in this policy in the following days, and +</I>><i> > will take care of making the necessary changes to the existing packages +</I>><i> > once we agree with the above points. +</I>><i> Be sure to have it generated with gem2rpm, and try integrate the +</I>><i> policy back into +</I>><i> gem2rpm again, I've created a public repository for my fork at: +</I>><i> <A HREF="http://gitorious.org/rpm5distro/gem2rpm5">http://gitorious.org/rpm5distro/gem2rpm5</A> +</I>Thanks for the URL, actually I started modifying the erb template in +gem2rpm, but will clone this and make pull request on this one then :) +(and package it as well) +><i> +</I>><i> (I might've added some additional confusion in trying to answer some of this, +</I>><i> don't be afraid to ask on things where I don't make sense;) +</I>><i> -- +</I>><i> Regards, +</I>><i> Per Øyvind +</I>-------------- next part -------------- +A non-text attachment was scrubbed... +Name: not available +Type: application/pgp-signature +Size: 230 bytes +Desc: not available +URL: </pipermail/mageia-dev/attachments/20110108/d3a46434/attachment-0001.asc> +</PRE> + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="002009.html">[Mageia-dev] [Cooker] [RFC] Ruby packaging policy +</A></li> + <LI>Next message: <A HREF="002010.html">[Mageia-dev] Adding Java-Policy +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#2011">[ date ]</a> + <a href="thread.html#2011">[ thread ]</a> + <a href="subject.html#2011">[ subject ]</a> + <a href="author.html#2011">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev +mailing list</a><br> +</body></html> |