Slax author's Blog (RSS)
02
December2012
Slax bundles and build scripts
I've received some valuable feedback on Slax buildscripts, which I mentioned in one of the previous blog posts. Several questions has been asked so I'll answer them. The idea is following: users will write build scripts for Slax, and they will be able to submit the scripts to Slax server so the server can make (compile or whatever) the binary Slax Bundles (.sb) automatically. The reason for this is that with each new Slax release, all binary bundles may be updated (recompiled or whatever) automatically so they will always work. Another good reason is that it will be much easier to check if the bundles contain only safe software, since users will not submit any binary packages, only the recipe.
Why not to use existing slackbuild scripts, for example those which are at slackbuilds.org? Well, there are several reasons I don't like them. Main reason is the poor quality of the code. Don't understand me wrong, I'm sure all the build scripts work properly. But my purpose is to provide unified way of writing them. For example, most slackbuild scripts include some long code to check architecture at the beginning, then some other long code to make temporary folders and unpack sources to them, etc.
If there is a well-designed template, with unified way to perform these tasks easily with just few command, it will be much easier to read and maintain such build scripts. As an example, instead of 20 lines of code at the beginning of the build script, there can be just something like:
download_all_sources extract_all_sources init_bundle_target_dir activate_dependencies
Another thing is dependency tracking. I don't want the automatic dependency tracking which I was trying to make with the old Slax 6. It made more problems than it should. So this time I would like to let the dependency be set by the buildscript creator. For that purpose, the buildscript will just include two variables. Lets see an example:
SLAX_BUNDLES_REQURED="lib1,lib2,lib3" SLAX_BUNDLES_REQUIRED_TO_COMPILE_ONLY="perl,cmake"
The slax build script will simply activate all dependencies before it starts the actual work. This will provide useful info to the user who is reading the script as well as to the server which will automatically activate all dependencies before the compilation starts.
What if there are multiple submissions for the same packages? Well, every build script will need to have unique name. Lets say ffmpeg. The first one who makes buildscript for ffmpeg will become the owner and maintainer, and nobody else will be able to submit build script with the same name (unless some selected admin decides). Thus if the user wants to build some software which requires some other library, then he must firstly write buildscript to make Slax Bundle with the library, and then he can include that dependency in his build script.
If somebody decides to include libraries together with the software, well lets be it. As long as there is another slax buildscript submitted for the given library, others can continue using it, there will no longer be a problem if a library is in several bundles (as this made some troubles for Slax 6, if you remember).
I hope that these my ideas will work out. I appreciate all your feedback on this, it is possible that I've overlooked something important, so all your comments are really welcome.
User comments
Sounds great, this will definitively raise the trust-bar for Slax bundles.
Do you plan to also support build-scripts in the dev-bundle? Like maybe another script to somehow replicate the automatic build environment on your server. It could be a huge time-saver for maintainers and easy to do experiments without hurting your hardware ;)
Will txz2sb, or tgz2sb still be available?
There are many packages that are available as slackware packages that might not be available in slax and *are* required to build some packages, i.e, bison, flex, ed, and others(development tools), that might not make the final devel module in slax to build software.
Can one just build/install the software for one's own and make our own module for personal use?
If we make a build script that requires a chain of deps. Things could get messy and require other's build scripts :(
There are several programs that I like to use/want to have on slax, but building these packages will require some work on my part and don't have some packages which are needed to build these. When there's another RC(release candidate) which has devel tools, I can see how I can tackle this issues. I know that vonbiber is very helpful when building software on slax, he has a script called slaxgenerator, I hope we can somehow make use of his expertise on the build scripts for slax. What do you think of this?
i like the idea of a single maintainer per module, Slax 7 is looking even more promising than just a big update of 6.
i just have one or two questions, let's say you have Gimp 2.8.2 module but two versions exist, the one in SVN/GIT constantly building and Stable release but they still 2.8.2;
a) What if SVN/GIT nightly builds comes first than the stable releases, is the stable package being discarded as "already there"?
b) in the case you let two instances of the same program exist as long as they are marqued Stable/Unstable, what if others users can submit newest build more constantly than the current maintainer?
i have some bunch of questions left but i'll keep my beans for now, thanks for your work man, it's awesome alternative
If there are more versions of the same software of gimp, eg. stable and SVN/GIT, then the stable version should be called "gimp" and the svn version should be called "git-unstable" or "git-svn" or something. Users will be then able to use either stable or unstable version.
Actually the build script will not track newest versions itself. It will be written to build just one particular version. If users need newer version, they have to contact the maintainer, who can either update the build script or provide password for his buildscript to someone else (who will become the new maintainer). It is a good suggestion to maybe mark some modules as 'bleeding edge' so they autoupdate maybe daily from SVN/GIT/etc... but for now I would skip this feature, thus git-svn would need to be updated manually by reuploading by the maintainer.
Looks great, but I hope this won't provoke a "maintainers race", in which many people submit poor quality scripts just to become maintainers and at the same time troubling the server administrators with the manual scripts checking, thus delaying bundle releases.
Something about this "finders keepers" strategy bothers me.
Thanks.
Ah, that is something I didn't think of, thank you for mentioning this Lacovisk. We will see; if this happens then I'll probably have to limit the amount of submissions from certain IPs, or even countries.
Sadly like Lacovisk mentions, there will be a race, and a great many people will want recognition as to their buildscript(s). I will still like the option of building from source from within slax(using the sources of the software plus the required deps, which may/may not be present in pristine slax). Then adjust, test and test to see that the app works for one(s) own use. The build script idea, has to take into account the deps and then things will get very messy with many people writing different packages(buildscripts) with different versions :( This is my take on this issue.
If I understand good, the buildscripts are meant to be something like Arch Linux' PKGBUILD?
"i like the idea of a single maintainer per module,"
Work in theory but not in practice.
Some people will submit a buildscript when they newly discovered the "wonder" of slax or when the build a module (via build script) for a particular module which they required.
Then either they move on to other distro or they are not really interested in maintaining it.
You can see the trends from slax 6 modules.While there are users who submit numerous modules are active on the forum, there are also some who submitted a few modules , and you no longer hear from them on the forum.
Will there be automated, pre-built packages from Slackware, like in Slax 6? I thought this was a nice feature, to get a number of handy, stable packages out there right off the bat.
@jcosh: I think we can solve the problem with inactive maintainers by stating that if a module maintainer is requested to fix his buildscript and he refuses or ignores it for more than 14 days, then the buildscript is free for anybody else to modify and become new maintainer
@parrothead: I plan to make simple buildscripts for all Slackware packages, but I'm not sure if I can properly autodetect the dependencies. Should be possible though, as I did that few times before.
I imagine that firefox-v.9 and firefox-v.9.1 could be owned by two different maintainers. Is it the case?
Good morning guys, how Jcsoh said up there, there are people who cast a module and not updated, I myself am one of those, I had to compile the drivres for video VIA for my netbook, it took me a week to learn how to do this, hence, happy with my work, I decided to share it with the community but I have no knowledge nor enough time to keep them updated, and this business of dependencies still causes me headaches. In my work I use Slax with some modules created specifically to solve the problems I encounter in my lab, these modules would not be much use to others, are scripted to put icons on the desktop or to back up certain directories, so things . I'll be able to handle these modules with a command like (dir2sd, sd2dir) as did in Slax? I hope so, that's what I like most in Slax, flexibility and ease of customizing it. Anyway, I liked the idea proposed, it will be one that I will learn, as I learned to build with Slax! thank you
(14) Griwwjack
I believe there is a lot of user like you. As you said , they go thru a lot of trouble to create a specific module they need , and rather share it . However , maintaing and updating the module may be more work than they are willing to do, bearing in mind they may stick to using the same module without updating for a long time.
Personally as a user I rather have an older module to use rather than none.
Actually my intention is not to force people to become "maintainers" of their modules. If they do not want to maintain them, then there will be a process how any other interested user can take over the module.
I'm not sure if this has been answered, (I can't find the answer) and its been asked by at least one other person (Tonio) - what if we just want to build a module for ourselves and not share it? I might not want to make a clean, "by-the-book" module because perhaps that particular software needs some tricks and tweaks or perhaps I only have the binary and some config files but I want to make a module. Previously I would just create a temp directory as a fake-/, put the binary and config files in its correct directory structure under the fake-/ and run dir2lzm. Can I still do this? Will dir2lzm, lzm2dir, tgz2lzm/txz2lzm still exist?
Perhaps FORCE the slaxbuild method if people want to upload their modules, but please retain the dir2lzm, lzm2dir, tgz2lzm functions for those who want to create their own modules which are not meant to be shared on the slax website.
Thanks.
@MarkDS: actually you can do the same, you can use 'dir2sb' command for that. It will be the same like before. The requirements for clean build scripts is there only for the users who want to SHARE their modules. Exactly as you suggested :)
Hi MarkDS, there is dir2sb in Slax7.
For sb2dir, loop-mount as squashfs should work.
For txz2sb, you can installpkg with -root, then use dir2sb.
I think I should add those simple scripts to Slax too, to make it easier for people to manage their modules.
What about deb2sb,txz2sb &tgz2sb , for conversion of debian and slackware packages.
Thanks Tomas and Dimitrij. I was under the impression that the final Slax7 would remove them, but its good that the same functionality as before will be around.
I support this idea. But what about support build-scripts in the dev-bundle or allowing peoples to setup their own buildserver and use it?
Ability to replicate build environment from official Slax server allows maintainers to test build process or support custom builds.
Each Slax will be a ready-to-use environment to process build scripts. The server will be just Slax running in virtual machine (separated from the webserver, for obvious reasons)
I just finished testing my buildscript for k3b. I prefer k3b to burn data backups.
According to the docs, it requires only cdrtools and dvd+rw-tools. But it actually needed libkcddb, libsamplerate. So, I made buildscripts for these as well.
I hope someone can look into these buildscripts and let me know how to improve them. I am not sure I did things properly.
Sign in with Facebook
Sign in with Google
Sign in with Email
It looks good. I hope that it works.