packaging March 2012

packaging@lists.fedoraproject.org

15 participants
13 discussions

Get paid to package! (Etherpad Lite)
by Rich Jones 20 Feb '13

20 Feb '13

Hey all! I didn't post this bounty, but it came across our system and it seems like you guys might be able to earn a quick bit of money on this one: http://gun.io/contracts/16/rpm-based-install-for-etherpad-lite-on-rhel-128 Any takers? -- Rich Jones Director, Gun.io

7 6

Ruby guidelines draft - further discussion
by Bohuslav Kabrda 04 Apr '12

04 Apr '12

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

2 3

alternatives --force (removing an old init script)
by Ricardo Rocha 26 Mar '12

26 Mar '12

(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

2 2

Ruby interpreter independence needs more work
by Toshio Kuratomi 22 Mar '12

22 Mar '12

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

2 1

New packaging guidelines for Ruby
by Vít Ondruch 21 Mar '12

21 Mar '12

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

9 34

Re: [Fedora-packaging] Summer coding idea
by Buddhike Kurera 08 Mar '12

08 Mar '12

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(a)fedoraproject.org | IRC: bckurera

1 0

Ada guidelines changes
by Björn Persson 07 Mar '12

07 Mar '12

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

1 0

RPM doesn't conflict
by Nelson Manuel Marques 07 Mar '12

07 Mar '12

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

3 2

Installing GConf schemas
by Vinzenz Vietzke 06 Mar '12

06 Mar '12

Hi, I'm trying to package polly [1] for F16. Everything works fine but obviously the package makes GConf schemas only available for root, not for normal users. Any hints on where my mistake is? Spec: http://vinz.fedorapeople.org/polly/polly.spec Src: http://vinz.fedorapeople.org/polly/polly-395bzr.tar.gz Regards, vinz. -- Vinzenz Vietzke Fedora Events Ninja / Coordination German L10N Team Mail: vietzke(a)b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

2 1

New packaging guidelines for Ruby
by Marcela Mašláňová 06 Mar '12

06 Mar '12

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

2 1

GSoC 2012 ideas - support expanding the list
by Buddhike Kurera 06 Mar '12

06 Mar '12

Hello Folks, Please add your ideas and expand the GSoC 2012 idea list[1]. Ideas and mentors welcome, thanks. [1] http://fedoraproject.org/wiki/Summer_coding_ideas_for_2012 -- Regards, Buddhike Chandradeepa Kurera(bckurera) Fedora Ambassador Sri Lanka Event Liaison - Design Team Email: bckurera(a)fedoraproject.org | IRC: bckurera

1 0

Icon tag in spec files
by Bruno Wolff III 05 Mar '12

05 Mar '12

I have a request (bz 787335) to add an Icon tag to the spec file for freecol so that the appropriate icon will be displayed at: https://community.dev.fedoraproject.org/packages/freecol I don't remember running across any guidelines covering this. Is this something I missed? Is this something new that should be documented?

3 3

Packaging legacy sysv initscripts and native systemd unit
by Jóhann B. Guðmundsson 02 Mar '12

02 Mar '12

Personally I never understood why this was allowed in the first place but given that we have all GA release on systemd now I'm wondering if the relevant section in the Fedora packaging guidelines "However, packagers who wish to include SysV initscripts may also do so" cant be changed to "However, packagers who wish to include SysV initscripts may no longer do so" ( or something similar ). Basically strictly forbid shipping both. It serves absolute no purpose shipping both legacy sysv init script and native systemd units. It did not do so from the start and it certainly does not do so now. There where few packages that went this route ( those supporting RHEL and Fedora put in an if statement if on red hat then install sysv init from what I observed ). Thanks. Jóhann B.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging March 2012