This sounds like a good feature to add to the site. It could simply be accomplished by listing the gems available for every Fedora version + rawhide along w/ their versions and other metadata.

This metadata can include a list of patches applied to the gem (as well as direct access to their contents if we wanted). We can extract this information directly from the (s)rpm itself.

Going forward, if we start standardizing on patch names, it might make it easier to automate parsing patch information from the srpm. I always try naming patches %{gemname}-%{version}-%{some general subject/description}

We will look at producing some mockups for this feature and implementing them as part of the GSoC (keep those suggestions coming!)

BTW as a related side note, I'm looking for a co-mentor for this project. The person will not have to do anything except for have their name appear on the list as a formality to the GSoC process. If you're interested please ping me on or off list (asap please as the final project evaluation deadline is in a few days)

Appreciate it,

On 04/15/2012 05:46 PM, Wan Zuhao wrote:
I do agree that it's very likely to miss out information such as patches and bug fixes applied if we rely on gem versions solely. 

Maybe we can compare the timestamp of the built rpm to that of the gem commits? Then we can roughly tell by the time the rpm was built, which patches have already been applied. Apparently this method can't be 100% accurate. I'm trying to figure out some other more reliable way, but I'm still kinda new to the Fedora dev community, so it will probably take some time for me to get a better grip on these. I'll have to dig deeper to see exactly what information is available.

By the way, could you please give some examples of such gem/rpm?



On Sunday, April 15, 2012 at 11:31 PM, Wan Zuhao wrote:

I see your point. 

On Sunday, April 15, 2012 at 9:37 AM, Jeroen van Meeuwen (Kolab Systems) wrote:

On 2012-04-14 21:08, Wan Zuhao wrote:
Hi Jeroen,

What you've suggested is definitely a good idea. I do agree it's
to reflect which *version*, in addtion to the name, link, etc. of a
particular gem that was converted into rpm, as sometimes the latest
and bug fixes are not included in the rpm.

The point is also, sometimes bug fixes (especially security issues)
*are* in fact included in the RPM, but the gem/rpm package version
number would not reflect that.

Kind regards,

Jeroen van Meeuwen

Systems Architect, Kolab Systems AG

e: vanmeeuwen at
m: +44 74 2516 3817

pgp: 9342 BF08
ruby-sig mailing list

ruby-sig mailing list