Tiny Core Extensions > TCE News
Guidelines for extension submission
Jason W:
Hi everyone,
The purpose of this post is to outline in some more detail the official procedure for submitting extensions. The wiki contains some important information on how extensions should be built:
http://wiki.tinycorelinux.net/wiki:creating_extensions
I won't recover all those steps here, but is important that extensions be built in accordance with those instructions to ensure that the extension will work well for other users and support our modes of operation.
The official channel for extension submission is the tcesubmit _at_ gmail _dot_ com email account. If you do not have access to gmail or the extension is over the size limit allowed by gmail, send an email to tcesubmit and explain that your submission cannot be emailed due to size and another means will be found. Once an extension has been submitted, please monitor the email account that was used for sending the extension in case there are any questions I may have about the extension. I am the team member who will be handling all submissions, and any questions you may have regarding your submission should be sent to the tcesubmit account until the extension is posted and an announcement is made. But if you see me on IRC or in the forum you can ask me about your submission there as well.
I check the tcesubmit account daily and I aim for a maximum of 24-48 hours turnaround time between extension submissions and a response. In the event I am away for more than that I will summon help from other team members so extensions should always be processed in a timely manner. If you have submitted an extension and you do not receive a timely response, please contact me or make a post about it in the TCE Talk area.
After an extension is uploaded to the public download area, a post is made in the TCE News section regarding the extension. Then testing and feedback on the extension can occur and be posted to that thread.
One very important issue is that of licensing. There is no way to cover all the facets of the different licenses there are out there, but rather I will just hit on a couple of key points. GPL licensed extensions need the original source, patches, and the build instructions used to create the binary. GPL'ed extensions cannot be accepted without these. If an extension is a GPL Debian binary, then the source files available on the Debian server must also be submitted with the extension. Be sure of the license and distribution policy before submitting as satisfying license requirements is a must. If the extension is not under a restrictive license, the source and build instructions still provide valuable information about the program and can help tremendously when trying to debug an extension. If in doubt, simply provide the source and build method as it only takes a minute or two at the time but is worth a lot later on.
EDIT: Providing download links to the source is perfectly ok. No need to upload what is readily available on the net.
EDIT2: If gmail is giving you problems blocking your extension, use bcrypt to allow it to be sent as then it cannot be scanned.
bcrypt extension.tar.gz
It will ask for a password, use "tinycore" as the password to keep it simple.
Hopefully the extension submission process will be a smooth and enjoyable experience for everyone. We greatly look forward to your contributions and thank you for support of this project. Any questions feel free to ask.
JW
softwaregurl:
Thanks,
a couple questions:
1. What is the size limit for gmail?
2. Are there any special considerations to not get hung up in a gmail spam filter?
(I ask because I have never had a gmail account.)
3. The compile instructions for my apache-2.2.8.tcel were included in the comments of the .info. Should this be common practice when they are very short?
4. You grabbed the tarball from the link I gave. Does this overburden you? I am on 900Mhz wireless...upload speeds are a little slow and I have nothing that supports resume on sending e-mail. A semi driving past is just enough that the transciever has to renegotiate and things fail. I do have other methods available, including downloading from one of my sites, if that doesn't work for you.
5. A clarification of file naming. You renamed from tce to tcel. I have seen something somewhere, but could not quickly reference it. As far as standardizing the name...[app name]-[version]? I am thinking apache-2.2.tcel would have been a better choice as I try to keeps up with the latest updates. What is the best way to indicate a "hacked" version?
Thanks again,
Juanito:
--- Quote from: softwaregurl on December 28, 2008, 05:45:23 PM ---...
5. A clarification of file naming. You renamed from tce to tcel. I have seen something somewhere, but could not quickly reference it. As far as standardizing the name...[app name]-[version]? I am thinking apache-2.2.tcel would have been a better choice as I try to keeps up with the latest updates. What is the best way to indicate a "hacked" version?
--- End quote ---
The "l" indicates that the extension libs are in /usr/local/lib and thus "ldconfig" is invoked by "tce-load" once the extension is loaded. In the same vein, an "m" indicates that the extension contains kernel modules and thus "depmod" is invoked once the extension is loaded.
It would be better to name the extension plain "apache" rather than "apache-2.2" so that when you update apache to a more recent version, you don't have to update any "dep" files that contain "apache-2.2"
Jason W:
I believe the size limit of gmail is I believe 20mb. So that would accomodate most any extension except those like Xorg.
I am not sure what gets caught in gmail's spam filter and what doesn't, but what is caught is kept in the spam folder which is now empty.
It is fine to have the compile instructions in the info file. I overlooked that at first, and quickly emailed back saying I saw it and that is was good. Either a seperate file or in the info file is ok.
I am more than happy to fetch the source from a link provided. My recent playing with dialup has reminded me of how spoiled I am with my 3.0 Mbit DSL connection. It is no burden to me at all and in fact me fetching source from a link costs me no time but saves others time. Either way for me the download time is the same. I just was in the old habit of including source myself when I uploaded but it is in no way a requirement; a link is fine.
As for extension naming, I added the "l" since there were shared libs in the exetnsion that needed ldconfig called upon for httpd to start without error. I just added it instead of emailing back asking you to. In the future if there are small clerical errors I will note any changes made in the info file by a response email. Of course, I will not edit the info file for content or make any changes to the extension itself.
With library extensions it is by far the best not to include the version name in the extension as that causes a lot of .dep files to have to be adjusted when the library extension is updated. For instance, gtk+-2.tcel can be updated without having to edit the content of any .dep files that call upon it. If if were named gtk+-2.12.11.tcel, then of course all the .dep files calling on gtk2 would have to be edited if gtk2 was updated to gtk+-2.12.12. But for apps that are not libs and do not have other extensions depending upon them, like leafpad, then it is not so important. But still I as a general rule leave the version number out of the extension name. Me, I would call apache-2.2.8 as apache2.tcel since there is also an apache 1.x out there.
If by hacked version you mean that non-standard patches were applied to an app or you changed the source on your own, then uploading the patches with the build info and mentioning that in the info file would suffice. I would mention it in the description as well. Sorry if I misunderstood the question, I think that is what you were asking.
I hope this helps.
JW
softwaregurl:
I was mainly thinking of complying with a license for hacked versions. I will continue with apache specific stuff in that thread.
Tons of great info, thank you much!
Navigation
[0] Message Index
[#] Next page
Go to full version