Hi Erkan,
A bit more info about SliTaz Next for your blog.
The goal is to have new and updated software that cannot be build on the regular SliTaz Cooking.
It takes more time than expecting to revive it. First, I'm bad with my time-management. Second, I want that work brought pleasure. SliTaz Next made great steps forward but (after the short period about a year ago) is still not ready to use. Here I'll write my TODO like I see it today.
I want to update the toolchain. After this step the whole repository should be rebuilt. Also I have some improvements after which the total rebuilding is also required. So I'll provide the improvements first, then update the toolchain.
"SliTaz Next" and "SliTaz Next64" isn't two different repositories. The repository is single, but supporting two different architectures. Recipes catalogue (wok) is single. It would be logical to provide single web interface to the cooker, as well as single folder for the packages on the mirror server.
Some packages are architecture-independent, like icon themes, fonts, or native Python and Perl libraries. So let's keep the rule for the packages naming:
- librsvg-2.42.2-i486.tazpkg is for "i486" architecture
- librsvg-2.42.2-x86_64.tazpkg is for "x86_64" architecture
- librsvg-dev-2.42.2-any.tazpkg is architecture-independent
In the most cases *-dev packages are arch-independent (if static libs are not inside), so we can save some space on the mirror reusing "*-any" packages for both architectures. And it is true for aforementioned icons, fonts, some Python and Perl packages. And we can split out the common architecture-independent part to the separated package, like here: http://cook.slitaz.org/next/nano/files
I already have a working functional script to determine the package's arch automatically after the compiled files has been split into sub-packages. It require some improvements (I have not yet realized the fact that not only the files may be architecture-dependent, but the paths too! See, for example, here: .pm file stands for "Perl Module", is a arch-independent script, text. But we can't pack similar files as arch-independent package due to arch-dependent path.)
It would be great to have some another entity above the two cookers (Chef or chief-cooker ☺) that will process all the queried packages one by one for both architectures, in parallel or sequentially:
- pkg1-i486 (in the i486 build environment)
- pkg1-x86_64 (in the x86_64 build environment)
- pkg2-i486
- pkg2-x86_64
- ...
If all the sub-packages are arch-independent (that we can mark with HOST_ARCH="any" in the receipt) it have sense to build it only in one build environment skipping it in other: result will be the same.
Currently tazpkg support is poor. It can only work with local cooker repository, and not trained to work with real remote repository (which isn't exists yet anyway).
Maintaining reliefs
Currently SliTaz Next web interface has some advantages over SliTaz Cooking one in the question of maintaining the packages. All the split packages in one place. As well as all the dependencies. All the files on the single page giving you information if you accidentally don't packed some files, or packed them twice. All files attributes also here, and wrong (or unusual) are red: (1) (2). But it will help you a bit when you need to review one-two hundreds of fresh built (for example, updated) packages. So I have a conception of post-build checks for many aspects (permissions, ownership and much more) that will give some "badges" to the package. These badges will be visible on the package's page, on the packages lists, and these badges will be search-able (like tags). You will find the problems on the first sight!
Little improvements
Such are not blocks the toolchain update, but here just for the record.
Advanced checking of the URLs (both home page and tarball). Sometimes projects moved from one web site to another, sometimes web site become HTTPS. In the most cases web servers send back the 301/302 and other HTTP codes to another locations, or 404/403/408 and other codes... To have actual and precise information is advantage. And Repology marks these "bad" cases as problems (not all the receipts was checked yet, updating in progress!), so we need to fix them.
Advanced helper. When you made brand new package, in most cases you'll find the dependencies. You found one, add it to receipt, start it, and it need some more. Repeat... It would be great to analyze common mistake messages and advice which package we need to add to BUILD_DEPENDS, or maybe it will be trained to add it automatically and to re-run the process! :-D
Advanced collision detector. Some different files with the similar path and name may be present in more that one package. It is bad situation. Don't ask me why. You know. But there's another, "advanced" problem that the different executables with the same name may be present in /bin/, /sbin/, /usr/bin/, /usr/sbin/, and... /usr/games/! To check these cases is to path to solve some odd problems.
Instead of conclusion
As always I have a lot of ideas, and a bit less free time and a will to implement them.
But I am stubborn :-D
Have a nice day!
