Dridi Boukelmoune dridi.boukelmoune at
Fri Nov 22 17:11:06 UTC 2013

On Fri, Nov 22, 2013 at 5:54 PM, Alek Paunov <alex at> wrote:
> 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 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.

The issue tracker is optional on github, that would only leave the
pull requests for fragmentation.

> --
> devel mailing list
> devel at
> Fedora Code of Conduct:

More information about the devel mailing list