diff options
Diffstat (limited to 'zarb-ml/mageia-dev/20110108/002009.html')
| -rw-r--r-- | zarb-ml/mageia-dev/20110108/002009.html | 208 |
1 files changed, 208 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20110108/002009.html b/zarb-ml/mageia-dev/20110108/002009.html new file mode 100644 index 000000000..542256e09 --- /dev/null +++ b/zarb-ml/mageia-dev/20110108/002009.html @@ -0,0 +1,208 @@ +<!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=%3CAANLkTi%3Di%3DRNVTixTrZAB5mkMiLEK8DWVi7pBCS_nATgV%40mail.gmail.com%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="002019.html"> + <LINK REL="Next" HREF="002011.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] [Cooker] [RFC] Ruby packaging policy</H1> + <B>Per Øyvind Karlsen</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=%3CAANLkTi%3Di%3DRNVTixTrZAB5mkMiLEK8DWVi7pBCS_nATgV%40mail.gmail.com%3E" + TITLE="[Mageia-dev] [Cooker] [RFC] Ruby packaging policy">peroyvind at mandriva.org + </A><BR> + <I>Sat Jan 8 05:07:55 CET 2011</I> + <P><UL> + <LI>Previous message: <A HREF="002019.html">[Mageia-dev] News of the front: first commits and mentoring start +</A></li> + <LI>Next message: <A HREF="002011.html">[Mageia-dev] [Cooker] [RFC] Ruby packaging policy +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#2009">[ date ]</a> + <a href="thread.html#2009">[ thread ]</a> + <a href="subject.html#2009">[ subject ]</a> + <a href="author.html#2009">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>2011/1/7 Remy CLOUARD <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">shikamaru at mandriva.org</A>>: +><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>\o/ +><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 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> +</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>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. +><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>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}). +><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>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. +><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>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.. ;) +><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 certainly think -doc subpackages are of use, but from what to dictate any +conditionals where and when to create such is something I'm not 100% on (I've +added support to gem2rpm to do it for files specified as documentation by the +gem metadata though), nor on *how* (should it be done by gem2rpm, +or perhaps automatically during package build from the metadata, in +similar fashion +as proposed for -devel packages above?), I'm able to implement (or +provide help in +doing so) the request once the desired behaviour has been figured out though. ;) +><i> +</I>><i> Normally %gem_* macros should take care of that, but we might have to +</I>><i> make it evolve. +</I>I think either way one should anyways try to keep as much as possible out of the +.spec files, leaving as much as possible up to macros, wrappers, dependency +extractors etc. to take care of. It'll help reduce maintenance work on +the individual +packages and help improve compatibility with other distributions. +><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>Be sure to have it generated with gem2rpm, and try integrate the +policy back into +gem2rpm again, I've created a public repository for my fork at: +<A HREF="http://gitorious.org/rpm5distro/gem2rpm5">http://gitorious.org/rpm5distro/gem2rpm5</A> + +(I might've added some additional confusion in trying to answer some of this, +don't be afraid to ask on things where I don't make sense;) +-- +Regards, +Per Øyvind +</PRE> + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="002019.html">[Mageia-dev] News of the front: first commits and mentoring start +</A></li> + <LI>Next message: <A HREF="002011.html">[Mageia-dev] [Cooker] [RFC] Ruby packaging policy +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#2009">[ date ]</a> + <a href="thread.html#2009">[ thread ]</a> + <a href="subject.html#2009">[ subject ]</a> + <a href="author.html#2009">[ 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> |