Hello,
the SUSE Security team would like to improve tracking of ruby gems bundled into packages, so that these appear in the metadata of binary packages. I am proposing https://build.opensuse.org/request/show/324759 This automatically generates "Provides: bundled(rubygem-foo)" without additional package maintainer action.
Please comment.
Andreas
On 08/21/2015 10:18 AM, Andreas Stieger wrote:
Hello,
the SUSE Security team would like to improve tracking of ruby gems bundled into packages, so that these appear in the metadata of binary packages. I am proposing https://build.opensuse.org/request/show/324759 This automatically generates "Provides: bundled(rubygem-foo)" without additional package maintainer action.
Please comment.
I like it a lot :) . It is very simple (which is great) and provides what it is needed.
I'd like to hear Darix opinion :-)
Andreas
On Fri, 21 Aug 2015 11:15:07 +0200 Jordi Massaguer Pla jmassaguerpla@suse.de wrote:
On 08/21/2015 10:18 AM, Andreas Stieger wrote:
Hello,
the SUSE Security team would like to improve tracking of ruby gems bundled into packages, so that these appear in the metadata of binary packages. I am proposing https://build.opensuse.org/request/show/324759 This automatically generates "Provides: bundled(rubygem-foo)" without additional package maintainer action.
Please comment.
I like it a lot :) . It is very simple (which is great) and provides what it is needed.
I'd like to hear Darix opinion :-)
we have 4 options of packages using gems
1. the good way: just requiring system gems and having nothing intree
2. the bad way: Buildrequires for the gems and then copying them into their tree.
3. the ugly: having all gems locally in the package as sources
4. the bad and ugly: a mix of 2 and 3
So let's looks at the options:
1. so the first option is what we actually want.
2. if you really find a valid reason to bundle (and so far none of the packages doing it had that!) we can solve this by maintaining a list of packages which bundle and then tracking their _expanded_ buildrequires list (osc buildinfo)
3. UGH. i guess you could just do "ls" on the source package and have a list of packages doing it.
4. as it is a mix of 2 and 3 you have to use 2 and 3 to solve it.
another option might be to look at all the binary rpms and see if you find any gems outside of the system gem dir (gem env gemdir). also keep an eye out for packages which have multiple gem files in their binary rpms. those are probably bundling too. but bundling into the gemdir.
HTH
darix
Hi,
On 08/21/2015 02:49 PM, Marcus Rückert wrote:
we have 4 options of packages using gems
the good way: just requiring system gems and having nothing intree
the bad way: Buildrequires for the gems and then copying them into their tree.
the ugly: having all gems locally in the package as sources
the bad and ugly: a mix of 2 and 3
As discussed, going forward it is probably the best to talk about the packaging policies to achieve #1. This could be supported with the appropriate rpmlint checks if someone would like to pick this up.
another option might be to look at all the binary rpms and see if you find any gems outside of the system gem dir (gem env gemdir). also keep an eye out for packages which have multiple gem files in their binary rpms. those are probably bundling too. but bundling into the gemdir.
The last option will help me solve the task at hand and should be easy enough to implement. The dependency generator will not be required as submitted.
Thanks, Andreas
On 08/21/2015 03:03 PM, Andreas Stieger wrote:
Hi,
On 08/21/2015 02:49 PM, Marcus Rückert wrote:
another option might be to look at all the binary rpms and see if you find any gems outside of the system gem dir (gem env gemdir). also keep an eye out for packages which have multiple gem files in their binary rpms. those are probably bundling too. but bundling into the gemdir.
The last option will help me solve the task at hand and should be easy enough to implement. The dependency generator will not be required as submitted.
Actually,in our case we are doing this in the spec file:
bundle install --local --deployment rm -rf vendor/cache
thus you won't find any .gem file.
This is because once installed you don't need the .gem file.
What counts on us is the Gemfile.lock or the dirs under vendor/bundle/ruby/..../gems/
Regarding using the buildrequires and the buildinfo to get a list of the gems, in our case we require some gems to compile the assets but they are not in the final binary rpm, thus it wouldn't work either.
I would go for the initial solution you proposed but change the __bundledgems_path to point to the directories instead of the .gem files. Plus an rpmlint check that checks there are no .gem files installed somewhere else.
Thanks, Andreas
Marcus Rückert darix@opensu.se wrote:
On Fri, 21 Aug 2015 11:15:07 +0200 Jordi Massaguer Pla jmassaguerpla@suse.de wrote:
On 08/21/2015 10:18 AM, Andreas Stieger wrote:
the SUSE Security team would like to improve tracking of ruby gems bundled into packages
An explanation of exactly what you mean by "gems bundled into packages" would have been helpful. I guess you mean
https://en.opensuse.org/openSUSE:Ruby_Gem_Strategies#Bundle_all_gems_into_on...
but the devil is in the details.
so that these appear in the metadata of binary packages. I am proposing https://build.opensuse.org/request/show/324759 This automatically generates "Provides: bundled(rubygem-foo)" without additional package maintainer action.
Please comment.
Based on that, I see
%__bundledgems_path ^.*/vendor/bundle/ruby/[^/]*/cache/[^/]*.gem
So it seems you are talking about using Bundler to install multiple gems into vendor/bundle/ at package build-time. Is that right? As Jordi already noted elsewhere in this thread, it's not safe to assume the presence of the packed .gem files.
I like it a lot :) . It is very simple (which is great) and provides what it is needed.
I'd like to hear Darix opinion :-)
we have 4 options of packages using gems
- the good way: just requiring system gems and having nothing intree
By "system" gems, I guess you mean the packages from d:l:r:e which provide one gem per package? And "intree" means a package containing multiple vendor/bundle/ gems? In other words:
https://en.opensuse.org/openSUSE:Ruby_Gem_Strategies#One_gem_per_rpm
- the bad way: Buildrequires for the gems and then copying them into their tree.
Blegh :) Why would anyone do that?
- the ugly: having all gems locally in the package as sources
By "as sources" you mean unpacked gems? Is there any other way to have them "in tree"?
https://en.opensuse.org/openSUSE:Ruby_Gem_Strategies#Bundle_all_gems_into_on...
- the bad and ugly: a mix of 2 and 3
So let's looks at the options:
- so the first option is what we actually want.
Yep.
- if you really find a valid reason to bundle (and so far none of the packages doing it had that!) we can solve this by maintaining a list of packages which bundle and then tracking their _expanded_ buildrequires list (osc buildinfo)
Not sure I understand fully but this sounds nasty to me.
UGH. i guess you could just do "ls" on the source package and have a list of packages doing it.
as it is a mix of 2 and 3 you have to use 2 and 3 to solve it.
another option might be to look at all the binary rpms and see if you find any gems outside of the system gem dir (gem env gemdir). also keep an eye out for packages which have multiple gem files in their binary rpms. those are probably bundling too. but bundling into the gemdir.
I guess I am maybe missing some context so I'm not sure I can contribute more to the discussion immediately, other than to make a plea:
Whichever way this discussion goes, please can everyone take collective responsibility to ensure that
https://en.opensuse.org/openSUSE:Ruby_Gem_Strategies
is properly maintained with correct and up-to-date info. Thanks!
-
Adam Spiers -
Andreas Stieger -
Jordi Massaguer Pla -
Marcus Rückert