Dne 26.4.2011 23:55, Mo Morsi napsal(a):
On 04/21/2011 05:29 AM, Vít Ondruch wrote:
> Hello everybody,
> Today I was contacted by Aleksandar Kurtakov and he proposed, that he
> would help us to autogenerate the RPM provides. This functionality is
> allowed by RPM 4.9 , it means for F15+. This would help Aleksandar
> for better RubyGem integration into rpmstubby  and at the end into
> Eclipse Fedora Packager .
> Basically we would need to place rubygem.attr (see  for maven
> example) file into /usr/lib/rpm/fileattr and script which would generate
> the provides (see  for maven example). Since this files are required
> during build, they should be probably part of rubygems package, although
> it has some cavities.
> In theory, this approach could also be used to generate Requires and
> BuildRequires from gem spec file.
> Any thought are highly appreciate.
Looked this over and I like the direction this is going, bringing more
automated dependency checking and analysis into RPM is a good idea, and
in conjunction with some additional Fedora policies (this is acceptable
to start integrating into Fedora correct?), it seems that alot of
developer effort would be alleviated.
The biggest concern that I have at this point is the dependency version
analysis, especially with the Ruby packages.
For gems we can parse version information out of the gemspec, for
bundler we can parse it out of the Gemfile, but we'll probably run into
some cases which this will not be enough, whether the dependencies are
not (or cannot) be fully represented or where there is no dependency
list per-se (in which case we might be able to get away with parsing the
'require's, there is a few ideas on how to do this here ).
One additional question I had is how easy it would be to override the
dependency generator. Lets say there is a mistake in the generator or a
use case that it does not work for and/or generated incorrect
dependencies for, will ruby packagers have to wait until that is
resolved to submit their packages. Will explicit dependencies in the
spec override the dependency checker?
In my understanding, there will be always both dependencies listed. One
set of dependencies will be generated automatically by some dependency
generator and there will second set of dependencies entered explicitly
in .spec file.