Are you new to package building? I was also not a fedora packager when I came on here, so I went through the online instructions to make sure they were as simple as possible, just the way package building should be. Lots of others are willing to help too, did you read the process on the website? On Mon, May 5, 2014 at 4:52 AM, Michal Altmann <michal.altmann(a)zonio.net <mailto:michal.altmann@zonio.net>> wrote: Hello, I would like to introduce myself as a packager of our product called 3e server.

I have a question about non-open source codes, because our product is free only for some limited count of users, we do not want to place source code in required SRPM package. I was thinking about some kind of installer, which download precompiled binaries from our website like in the case of flash plugin. Is this an only option?

Hi, thank you for your replies. My comment's are in the text bellow

On Mon, May 5, 2014 at 12:12 PM, Alec Leamas <leamas.alec(a)gmail.com&gt; wrote: >> I have a question about >> non-open source codes, because our product is free only for some >> limited count of users, we do not want to place source code in >> required SRPM package. I was thinking about some kind of installer, >> which download precompiled binaries from our website like in the case >> of flash plugin. Is this an only option? > No, you have multiple options: > - The most straight-forward would be to package a closed source package, e. > g., like the nvidia drivers. In this case you publish binary blobs, and > package those using the binary as "source" in the rpm sense. > - You might consider to publish your own repository. Creating a repository > is not hard. However, you will probably need some help to create the > packages first anyway. > - The installer solutions used for e. g., flash and spotify and steam > reflects the fact that the vendors does not allow redistribution of their > binary code. > > You might want to consider allowing redistribution or not before proceeding. > Allowing redistribution (like Nvidia) make packaging much easier. However, > since you don't have control in this case there is a risk that e. g., other > distributions might distribute outdated content. I think this is the reason > other vendors does not allow it, or just distributes an installer. > > > > cheers! > > --alec > Thank you for very useful explanation. After reading this : https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines, especially section 'No inclusion of pre-built binaries or libraries' I was a little bit confused how can we deal with it.

I had been in the same situation and there were others here that sponsored me. I'm a bit new to sponsoring though, otherwise i'd be glad to help. I can review it so it should pass sponsorship more easily, when you find a sponsor. hope it helps..

> BTW, I'd guess that unless you have some contacts the real bottleneck here > is to become sponsored. Your goal here is to package this particular sw. > However, becoming sponsored normally needs much more activity than that, > sponsors sponsor people after they have been active in much more than just a > single package. Also, it's sometime easier to get sponsored in Fedora than > in rpmfusion, but then you need to submit more packages. See [1]. Note that > if you're sponsored in Fedora this applies also to rpmfusion. >

On 05/11/2014 10:35 PM, Michal Altmann wrote: > BTW, I'd guess that unless you have some contacts the real bottleneck here >>> is to become sponsored. Your goal here is to package this particular sw. >>> However, becoming sponsored normally needs much more activity than that, >>> sponsors sponsor people after they have been active in much more than >>> just a >>> single package. Also, it's sometime easier to get sponsored in Fedora >>> than >>> in rpmfusion, but then you need to submit more packages. See [1]. Note >>> that >>> if you're sponsored in Fedora this applies also to rpmfusion. >>> >>> Can you specified "much more activity" please? > Not really, my impression is that it depends on the sponsor which eventually might look into this. There is input on this in [1] We would like to > package this software that consists from 4 separate packages and we > are ready to contribute by other packages, for example, we would like > to add Metalog that is not coded by us. > Before this is over, you would probably also need to contribute by doing informal reviews of other packages, as described in [1]. It's a question of demonstrating that you know the Guidelines. I thing that we have no chance to get sponsored directly in Fedora > because of non-free software as we found in guidelines. Maybe with 3rd > software such as Metalog. > Yup, that how it worked for me once in a time. I have a question about form of spec file for binary package. I am > thinking about fixed dist and arch field. It is the right way to > create SRPM directly for the target system, that can run the binaries > ? What Ferdora release are you prefere for the first review ? > > You're better off using Rawhide i. e., the upcoming Fedora 21 . Depending on if/when this is completed, you might want to add a F20 version (current release) as well. This is really nothing you code into the spec, it's handled when you check it in into the VCS system (which is good o'l CVS on rpmfusion, git on Fedora). In those there is a specific branch for each Fedora version, so the differences such as the different sources is reflected there. The differences in this case between F20 and rawhide/F21 should normally just be one or two macro definitions unless you are using some cutting edge functionality which isn't available in both versions. You should try to make the spec as generic as possible, it helps a lot when maintaining it later. Cheers! --alec [1] https://fedoraproject.org/wiki/How_to_get_sponsored_ into_the_packager_group