Ruby guidelines draft - further discussion
by Bohuslav Kabrda
Hi,
as it was said on the fpc meeting, I'm writing to comment on the section "Some Notes" in Toshio's draft of new Ruby packaging guidelines [1].
[citing the lines from "Some Notes" one by one]
- "Need to move the rubygems library into the per-interpreter directories as it is a non-gem library."
As we have said with Mo Morsi, Rubygems library should stay out of Ruby directory structure.
Pros:
-- Prooves to Rubygems and JRuby upstreams that Rubygems library can be unbundled from Ruby and it makes sense to work on merging the JRuby changes in Rubygems upstream to make one general Rubygems library (that should therefore be implementation-independent).
-- As noted by Toshio on the fpc meeting, our system-wide Rubygems are currently only used by MRI Ruby. But as I've said, we need to take steps gradually to convince the upstreams of feasibility of such changes and not to break anything. It is true, that JRuby currently ships with it's own modified (non-compatible) version of Rubygems, but we are working to merge their changes into Rubygems upstream. So yes, currently in F17, there is only the MRI Ruby using the system-wide Rubygems, but the support for JRuby is comming (perhaps F18?). If we are discussing this only from F17 point of view, we still may want to package Rubinius there (it is on our todo list, although not that high as JRuby) and Rubinius _would_ be able to use the system-wide Rubygems - that is another reason why Rubygems should stay where they are even in Fedora 17.
Cons:
-- Toshio says that he doesn't like special-casing and Rubygems should ship inside each of the Ruby implementations, until we make all the changes to have system-wide Rubygems, that work with all Ruby implementations (I hope I am not misinterpreting you, if yes, then please correct me). I'd like to add, that it is very hard to convince Rubygems upstream to make any changes that we need and we must have something to show them it's worth the work to merge the JRuby changes in.
-- Any others?
- "Need to rebuild ruby and rubygems package to use the new location"
-- I think that depends on whether the Rubygems library is moved, so let's put it aside for the moment and discuss it afterwards.
- "Need to rebuild rubygem packages to use the new interpreter-neutral rubygem library location."
-- Same as above.
- "Should there be more information about jruby, etc in the introductory portion (naming and" [unfinished]
-- I think it would be good to postpone this until we have better integration with the other Ruby implementations. So far, no one has requested any JRuby specific packages or anything connected with JRuby, so I would leave that for a separate discussion/fpc ticket.
- "gem2rpm and rpmdev-newrpmspec can be updated with the new template"
-- Yes, we will do that once the guidelines are complete. I hope that the gem2rpm part of guidelines will then be added back.
Thanks for reading this through :)
--
Regards,
Bohuslav "Slavek" Kabrda.
[1] https://fedoraproject.org/wiki/User:Toshio/RubyPackagingDraft#Some_notes
12 years
alternatives --force (removing an old init script)
by Ricardo Rocha
(resending after subscribing to the list)
Hi all.
The lcgdm packages are using alternatives, as several flavors are
provided - mysql, postgresql, ... backends.
While trying to provide an upgrade path to some of our users taking
legacy packages - as in from other repositories, not fedora - by using
obsoletes/provides i've bumped into an issue with the upgrade of the
init scripts. The old packages are not using alternatives, so the
init.d script is an actual file, not a symlink. While upgrading to the
new fedora package (which would obsolete/provide the old ones), the
old init.d script is left there, as it's a real file. This breaks the
service as the daemon binaries are now (as they should) in /usr/sbin -
they used to go in /usr/bin.
Debian seems to provide an option for these cases:
# man update-alternatives
"""
If some real file is installed where an alternative link has to be
installed, it is kept unless --force is used.
"""
but i can't find anything similar in Fedora. Is there a solution other
than documenting that people should remove the old package and install
the new one in two steps?
Thanks in advance,
Ricardo
12 years
Ruby interpreter independence needs more work
by Toshio Kuratomi
Since limited interpreter independence is a goal of the new guideline
(limited to rubygems), there needs to be more work done ironing out a few
details of that:
* It seems that the ruby(abi) Provides is only in ruby-libs; not in
jruby{,-libs}. That means that an end user wanting to use jruby and having
only rubygems installed still needs to have ruby-libs installed (because
of the dep on ruby(abi).) Is this intentional?
* There needs to be more information about jruby and other alternate
interpreters. In particular, the path macros for the jruby non-gem
packages need to be added.
* I took a guess that non-gem packages should have separate
subpackages for each interpreter since the thought is that rubygems can
handle multiple interpreters but non-gem requires cannot. Further,
I guessed that they should be named INTERPRETER-module, for instance,
jruby-rpm. The answer to whether jruby should Provide ruby(abi) is no,
we also need to specify what non-gem packages for other packages should
require (for instance, jruby(abi) = %{jruby_abi}). If the answer is yes,
we may still need to add new Requires for non-gem packages so that they
are only associated with the correct interpreter (however, we might not
need to have matching Provides... we might be able to just use package
name for this)
-Toshio
12 years, 1 month
New packaging guidelines for Ruby
by Vít Ondruch
Hi,
since I was not subscribed to this mailing list, I starting new thread
in Hope to move forward with the packaging guidelines. There are still
some outstanding issues.
= Mandatory rebuilding gems =
Yes, Ruby SIG is still against it, since there is known just one gem ATM
which needs such treatment. Now I list several pros/cons:
Pros:
* It would allow ruby packages to follow the same steps as other packages.
Cons:
* More overhead for maintainers.
* More confusion for new-commers, since this approach is not know in
Ruby community and there is no best way how to achieve it.
* There is only one known gem in Fedora, which needs this treatment ATM.
* If you need patch binary part of gem, it is sign that the gem is not
well maintained by upstream, otherwise it would not be needed.
= Vendorlib =
It is not good idea to move vendorlib out of the Ruby directory
structure. Actually it is pair of directories, vendorlib and
vendorarchlib. These directories are typically used by libraries Ruby
bindings, such as geos, subversion, etc. This platform dependent
bindings has no meaning to other Ruby implementations, such as JRuby.
= ruby(name) vs rubygems(name) =
Although we want to see as much libraries as possible provided in a gem
form, there still be some libraries which are not gemified. However,
Gemifies library *should not* always provide also ruby(name) virtual
provide, since these are not always simply interchangeable. Gem caries
with itself its metadata. When gem is loaded to Ruby's library path,
this metadata are processed as well and it might put some other
dependent libraries to Ruby's library path as well. In contrary, the
ruby(name) provide will mean that it is not gemified library, so I would
prefer to stay with distinction between ruby(name) and rubygem(name).
Gem would provide the ruby(name) only in case it obsoletes previously
available ruby library.
These are 3 concerns I remember was the most controversial. Please feel
free to share your thoughts.
Vít
12 years, 1 month
Re: [Fedora-packaging] Summer coding idea
by Buddhike Kurera
On Wed, Mar 7, 2012 at 10:52 PM, Anuj More <anujmorex(a)gmail.com> wrote:
> Hello,
>
> I was thinking of porting something like AUR (Arch User Repository) to Fedora.
> I have blogged about it, and any feedback about the feasibility,
> technical issues, is appreciated.
>
> Link to blog post: http://execat.blogspot.com/2012/03/aur-clone-for-fedora.html
>
> Also, do you think it's worth adding to this[1] or this[2] page?
>
> Thanks!
>
> [1]: https://fedoraproject.org/wiki/Summer_coding_ideas_for_2012
> [2]: https://fedoraproject.org/wiki/Summer_coding_ideas_for_2012/Students_Idea
> --
> Anuj
> Visit: https://fedoraproject.org/wiki/User:Anujmore
Hello
I am forwarding the mail from the summer-coding list.
Any idea, support is welcome, thanks
--
Regards,
Buddhike Chandradeepa Kurera(bckurera)
Fedora Ambassador Sri Lanka
Event Liaison - Design Team
Email: bckurera@fedoraproject.org | IRC: bckurera
12 years, 1 month
Ada guidelines changes
by Björn Persson
I would like to propose some changes to the Ada packaging guidelines.
Proposal:
https://fedoraproject.org/wiki/User:Rombobeorn/Ada_Guidelines_Changes
Trac ticket:
https://fedorahosted.org/fpc/ticket/154
The following is a brief summary of the changes. See the wiki page for the
full proposal.
· There is currently a rule that a -devel package must not contain all the
source files of the library. I think this rule should be removed, because it
causes a lot of work for very little benefit.
· The macro GNAT_optflags has been replaced with Gnatmake_optflags and
GPRbuild_optflags, and the guidelines need to be updated to reflect this. The
guidelines should also mention that some other macros might need to be used if
the underlying GNAT tools are invoked directly.
· The macro GNAT_arches shall be used when there is a need to prevent attempts
to build an Ada package on some secondary architectures.
· The value of _GNAT_project_dir has been changed to "/usr/share/gpr".
· The guidelines page should be moved from the Packaging guidelines drafts
category to the Packaging guidelines category.
Björn Persson
12 years, 1 month
RPM doesn't conflict
by Nelson Manuel Marques
Hi all,
I would like to clear a doubt if possible regarding the installation of RPM's and potential conflicts. Here's somehow a twisted use case:
1) 2 RPMs: foobar-1.0.noarch.rpm and foobar-2.0.noarch.rpm
2) Both RPMs have exactly the contents: %{_sysconfdir}/foobar.conf
3) The contents of the file foobar.conf are the same in both RPM's, it has a single line with: Hello World!
Now, if I do:
# rpm -ivh foobar-1.0.noarch.rpm && rpm -ivh foobar-2.0.noarch.rpm
Both RPMs install perfectly. Please notice I'm doing '-i' and not '-U'. Is this the intended behavior of the RPM ? Shouldn't it return a conflict because the file is already installed ?
If I change the contents of the file, so that both RPM's have the same file with different contents (which makes a different hash), the conflict does exist.
Anyone could clarify to me why one conflicts (which I believe to be the intended behavior using '-i') and if the files are exactly the same they don't conflict and it allows install...
Thanks.
Melhores cumprimentos,
Nelson M. Marques
12 years, 1 month
New packaging guidelines for Ruby
by Marcela Mašláňová
Hello list,
could we start with the discussion about the packaging guidelines for
Ruby once again? The discussion is very long and I guess everyone is now
lost in too many details.
I'd like to propose going over the whole guidelines, from a paragraph to
a paragraph, so it is clear what is okay and what is not and why.
>From previous emails it looks like the discussion stalled and arguments
are only repeated over and over.
I believe whole Ruby SIG agreed on the guidelines. Would it help if more
people from SIG participate in this debate? Or would it be more specific
examples helpful?
Ruby is not like Perl or Python. It has its own specific ways. Upstreams
are usually not happy, when distribution change those specifics too
much. Some packages are hard to package into rpm and we need to do some
hacks around, which bring more comfort to packagers.
Please take a break for few days in this discussion and start again.
Regards,
Marcela
12 years, 1 month
