Other distro's packages -- let's get the conversation rolling!

[LichenSymbiont]

I was checking out distrowatch for the first time in months, and from the popularity page, I see that TC is on the rise.
http://distrowatch.com/dwres.php?resource=popularity
And while checking for interesting distros, and thinking of why they are popular to begin with, I missclicked on a distro I've not even heard of: Kwort. With a package manager, named kpkg, with specially compiled packages.
Sounds like something using KDE, right? But it's just Openbox and GTK programs, and based on CRUX.

This is just to list some possible targets, and perhaps finding out how to go about it.

As I think having scripts or compiled package managers for using other distro's packages is an inevitable, as dCore has certainly made me think of this possibility.
Imagine if we could run Arch Linux, Gentoo, Slackware just by selecting it before installing.
I can't really find anything unique from distrowatch, as 99% or something are just flavors.

So by installing packages from any of the distro's by just switching package manager, or mirrors, it will be a great deal simpler than Puppy Linux in that aspect.
And hopefully flavors will arise from sharing installation scripts, config files and .sce packages.

Exherbo: exherbo.org
Using the Paludis package manager for Gentoo ebuilds, which is programmed in C++, and greatly simplified as compared to Gentoo's Portage. So the core is significantly lighter, by not having Portage and it's Python dependency.
paludis.exherbo.org

Void Linux: voidlinux.eu
With both binary and for building from source like in Gentoo.
Here is a sample of the build-file for Firefox in Void Linux: https://github.com/voidlinux/void-packages/blob/b4f8bd1a4d0f4ded8dfee4b829a98fa49f15c7b3/srcpkgs/firefox/template

Any other interesting distro's or package managers?

[Jason W]

I did have an effort at the Arch Rollback Machine, mentioned in the other thread.  Very simple and doable, much less startup script magic than Debian.  But Debian types are much more in keeping with dCore as a whole. 

[hal9king]

I think the Slackware 'SlackBuild' approach has merit -- particularly for maintaining tcz packages.

[Jason W]

I used Slackbuilds and more often Arch PKGBUILD scripts and patches to make my own tcz build scripts.

[jls]

Hi
also tc used to have some build scripts: https://code.google.com/p/tc-ext-tools/

[yoshi314]

Exherbo: exherbo.org
Using the Paludis package manager for Gentoo ebuilds, which is programmed in C++, and greatly simplified as compared to Gentoo's Portage. So the core is significantly lighter, by not having Portage and it's Python dependency.
paludis.exherbo.org

well, that was a good laugh. paludis is quite complex,  just look at a truckload of options it offers. maybe dependencies are sane, maybe not,  you want simple - either look at pacman (archlinux), apk ( alpine) or pkgcore (gentoo's yet another alternative package manager).

i am considering adding a hook to it to build tc packages out of builds, to create a custom TC hybrid system. currently experimenting with the package manager to see if i can pull this off.

[LichenSymbiont]

Perhaps Paludis isn't simple to use, I wouldn't know, as I've yet to use it. But I've found ways to simplify parts of its code, as it keeps things nicely encapsulated. And that was just in a fifteen minutes of looking at it.
So there is a great potential for simplification, at least. Unlike Portage, which is messy procedural code.

And of course Pacman is simple to use, but Paludis builds Ebuilds and can install binary packages as well. So it's probably the best for Gentoo packages.

I did have an effort at the Arch Rollback Machine, mentioned in the other thread.

Sorry Jason, if it seemed like I was ignoring this response
I just wanted to come up with some good response, but all I could think of was "that's great!" or "interesting!".
It's simply the easiest way to get Arch packages for other distros.

So after really looking into it, I've decided I will try it with dCore.
Just a simple script that makes a package list from the repos on the FTP (http://seblu.net/a/arm/month/), and fetches the deps ( grep "depend" ./.PKGINFO | awk '{print $3}' | sed 's/\://g' ), and gets them before proceeding.
Perhaps placing all dependency packages in one base.sce, with a list of packages it contains, just to keep it simple. Too bad there isn't a read-write file-system as easy to use as SquashFS.

But I should fix my install script, so it's easier to test it, and get the install script properly tested as well...

I think the Slackware 'SlackBuild' approach has merit -- particularly for maintaining tcz packages.

Certainly. Just simple shell scripts: http://slackbuilds.org/slackbuilds/14.1/games/minetest/minetest.SlackBuild
But the packages in the FTP doesn't contain any dependencies.
So yes, not instantly useful, but useful for building your own packages, pretty easily.

I will at least stick to build-file formats with dependencies integrated (still anything interesting is interesting ^^).
So you can just check out the dependencies with grep on the  build-file, and check if any packages needs to be built or installed before proceeding.

Hi
also tc used to have some build scripts: https://code.google.com/p/tc-ext-tools/

Not bad!
With dCore we could have all kinds of package managers and build formats without any cost, just the time-cost to individuals that choose to play around with non-Debian packages.
Perhaps those scripts uses some tools that dCore doesn't have, but it could all be provided in a compressed file.

[Jason W]

I already have the script routine working, just would need an Arch packed base.  The thing is you have to get the deps recursively, that grepping and then grep the PKGINFO files for the deps, and then for their deps.

I can put it up if you want to try it out. 

[LichenSymbiont]

"Arch packaged base", are you refering to the initrd file-system? Or meaning just running it on the official Arch base?

The thing is you have to get the deps recursively, that grepping and then grep the PKGINFO files for the deps, and then for their deps.

So just grepping the deps recursively, and then placing all unique packages in list, I guess, and then reading the list from the end (as the lowest levels will be appended there).

So I would say having a Git repo on Github for these projects would be the best, as then we have all the code available, and anyone can refine it when they feel like it. Lowering the contribution-resistance.
I could just upload it on my dCore folder on my linux-scripts repo, if I may...

Hmm... maybe I can solve two problems at once for *Core and other distros:
*Fast dep-tree handling, and processing of various build and binary package formats.
*And a superior format for storing packages, with both read and write, and mount, by deriving a kernel-module from the SquashFS kernel module.
By handling these things in one small C/C++ program.
Where you access its functionalities through a script, like:

Code: [Select]

#first get the package with wget.
pkg-constructor --find-deps "$TCEDIR"/arch/firefox-38.tar.xz #stores it in pkg-constructors dep-tree

pkg-constructor --make-pkg "$TCEDIR"/arch/firefox-38.tar.xz "$TCEDIR"/sce/ #so this basicaly downloads all new deps with wget, and stores them in the arch package directory.

sudo mount "$TCEDIR"/sce/firefox-38.sce / -t mpkg -o loop #mpkg being the new compressed and mountable file-format for read/write.
So just for the things that are very heavy in script, and produces messy script.

I will really start this experiment, and see what happens. Finding and making a dep-tree out of deps in different package formats first. Then with direct access to the data-streams of package-files through zlib and the LZMA SDK, the info files can be read instantly, without extracting it all. And extracting and packaging in one go, without temporary files. You might even be able to download deps concurrently, if you can just extract the deps from a half-downloaded package.

I've long been interested in compression. So it will be interesting to refresh my understanding and motivation for it.

[Jason W]

A Core type initrd like dCore but based on Arch files.  Then the script finds dependencies, downloads and converts to TCZ packages all that are needed, and creates .tcz.dep and .tcz.md5.txt files.  Like Core but with the Arch repo. 

It is unofficial but I can post the script in programming and scripting.  I think there is some bugginess with the dependency handling, but there are always bugs in any first attempt at anything.  Then if anyone wants to play with it they can.  I personally don't favor LZMA since that slows file reading from the tcz/sce packages, but hard drive or even zip drive space is very plentiful for the percentage of larger gzip files.

[Jason W]

Actually, since we are talking about it here, I can post here.  Attached are the needed scripts, just place them in /usr/bin/

This is a test of concept, not everything or much will work without an Arch base.  But the importing routine can be tested for fun.

[LichenSymbiont]

Yeah, this looks great!
And now I see you can just find deps from the .db files!

[jls]

Hi
I can't see this for example: https://aur.archlinux.org/packages/places-git/

[Jason W]

Ok, I have not put any time into this since I made the prototype in February.  But I will take a look at it as time allows.

[mocore]

Any other interesting distro's or package managers?

http://en.wikipedia.org/wiki/Nix_package_manager
+
https://nixos.org/nix/about.html

It sounds intresting .., & aparently

Nix can be used, with some caveats, as a package manager on top of an existing operating system, such as a GNU/Linux distribution. It may also be used to maintain any kind of file configurations, such as server setups, in addition to software packages in the strict sense.