Introduction

Dridi Boukelmoune dridi.boukelmoune at gmail.com
Wed Nov 27 14:56:08 UTC 2013


On Wed, Nov 27, 2013 at 2:01 PM, Tako Schotanus <tschotan at redhat.com> wrote:
>
> Sorry for not responding to this before, but lots of other things to do and this packaging business obviously needs more than just an hour here or there of reading READMEs.
>
> I see you want to make things even more difficult for me by giving me *several* options to choose from, are you *trying* to torture me? ;)
>
> Is there somewhere I can read up on this way of managing packages?
>
> And any particular reason why you would suggest making a new gitgub project for each of the Ceylon SPEC files instead of just putting them together? Wouldn't that just give us a bunch of 1-file projects otherwise?

I would say one spec per upstream repository (or per upstream source
tarball...). Of course it makes one-file repositories until you have to
patch stuff. In your case, you have binaries in your repositories (jar
files in /lib dirs) which goes against the guidelines. You might have
to patch the build.properties or build.xml files to "buildrequire"
rpms providing those jars in order to comply with the guidelines.

I could probably find more issues, but with my limited time I went
straight to the obvious :)

Dridi

PS. congratulations for the 1.0.0 release

> Thanks,
> -Tako
>
>
> ----- Original Message -----
> From: "Alek Paunov" <alex at declera.com>
> To: "Development discussions related to Fedora" <devel at lists.fedoraproject.org>
> Cc: "Tako Schotanus" <tschotan at redhat.com>
> Sent: Friday, November 22, 2013 5:54:53 PM
> Subject: Re: Introduction
>
> On 22.11.2013 14:58, Tako Schotanus wrote:
>> So I'm completely new to this packaging business, I managed to piece together a SPEC file that results in an actually working RPM for our project and even Koji seems to accept it, but there's so much information to absorb that I'm feeling a bit out of my depth. (Our project being a programming language we're dealing with some difficult issues with respect to versioning and such, for now I've copied Java's with alternatives and such which might or not be a good idea). So if there are some friendly people here that can guide me through my first real submission that would be great!
>
> I really don't know weather this idea is appropriate [*], but since
> Ceylon development is github based anyway and Ceylon is a fresh new
> development stack (according to Fedora.next terminology :-) ), what
> about new github account: fstack-ceylon (Ceylon related packages for
> Fedora) containing something like:
>
> gh:fstack-ceylon/ceylon/ceylon.spec
> gh:fstack-ceylon/ecliplse-ceylon-ide/ecliplse-ceylon-ide.spec
> ... etc
>
> formed in the same shape as the future dist-git repos (being drafts for
> them) for all the incoming Ceylon SRPMs.
>
> You could then clone/commit there your current .spec drafts and receive
> issues and pull requests containing packages improvements (e.g. with
> pointers to relevant guidelines parts) if it turns out that such style
> of community work on the specs seems efficient to the established
> packagers, who already offered help.
>
> I imagine few additional pros:
> - Ceylon stack packaging "story" collected under a github account can
> become a visible guide for the new stacks Fedora integration (especially
> for the potential contributors which are new to the tracking of the
> bugzilla.rh packaging bugs and the other Fedora communication channels).
> - the whole collection of the specs, when polished could be forked and
> tweaked for other RPM based distributions.
>
> Kind Regards,
> Alek
>
> [*] because 1) it seems that few voices are firmly against Fedora
> specific work on github and 2) this would lead to some bug-tracking
> fragmentation between github/bugzilla, but I hope the latter is more
> technical (synchronization/indexing) issue.
>
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


More information about the devel mailing list