On Wed, Nov 27, 2013 at 2:01 PM, Tako Schotanus <tscho...@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" <a...@declera.com> > To: "Development discussions related to Fedora" > <devel@lists.fedoraproject.org> > Cc: "Tako Schotanus" <tscho...@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@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
