dCore Import Debian Packages to Mountable SCE extensions > dCore X86

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

<< < (2/4) > >>

yoshi314:

--- Quote from: LichenSymbiont on May 06, 2015, 07:18:39 PM ---
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
--- End quote ---

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.


--- Quote ---I did have an effort at the Arch Rollback Machine, mentioned in the other thread.
--- End quote ---
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...


--- Quote from: hal9king on May 16, 2015, 09:27:07 PM ---I think the Slackware 'SlackBuild' approach has merit -- particularly for maintaining tcz packages.

--- End quote ---
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.


--- Quote from: jls_legalize on May 17, 2015, 04:16:00 AM ---Hi
also tc used to have some build scripts: https://code.google.com/p/tc-ext-tools/

--- End quote ---
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?


--- Quote ---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.
--- End quote ---
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: ---#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.

--- End code ---
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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page