Potential solution for lack of extensions - source based package manager

[blinkkin]

Main problem with Tiny Core Linux is small repository right now. I founded that creating new extensions is easy, but time consuming.

Source based package manager is one of the solutions. With auto downloading source and resolving dependency manager, maintaining extensions and keeping them up to date would be much easier. Here is short example of emerge used in Gentoo:

Code: [Select]

emerge --buildpkgonly gnumeric
This create *.tbz2 binary packages with all dependencies. Unpacking and compressing back to *.tce isn't problem. Besides emerge is writed in python, so hacking could be simple to get something like that:

Code: [Select]

emerge --tce gnumeric
There exist other "recipe" managers like: pkgsrc in NetBSD, moonbase in Lunar Linux, conary in  Foresight Linux, pacman with ABS in Arch Linux and emerge/paludis/pkgcore for portage in Gentoo (check also Gentoo Prefix).

Disadvantage is need of bootstraping an toolchain. This means that almost all code should be compiled using manager. Other problem is *.tcz, because symlinks doesn't work for all apps. Probably TCL wouldn't be called standalone distro anymore, but based on other.

In normal Tiny Core Linux manager could be removed. In dev edition TCL would be supplied with source based package manager.

This is just idea, let's start discussion. Sorry for bad/poor English.

[tobiaus]

i was thinking about this yesterday when i said: "in the future it should be easier to create websites that do custom distro builds before you even download the .iso." but i was actually thinking of a custom iso builder that used a binary (source included, as robert would insist) repository.

the compiling could/perhaps should be done locally, (i like your idea, if it's possible) but if the future includes tinycore servers that can compile source into custom isos, they could use your idea too. before then i'd like to see a second package manager / option that is capable of downloading and compiling source.

for general use i like what tc has, which is a very lightweight manager that doesn't require compiletc. perhaps it could include a compile feature (inactive) and then integrate with compiletc if compiletc is found. otherwise, it would download from the binary repository as usual.

i think even if you keep it simple like that, its abilities (what it would take to create it) would be very sophisticated. i've tried to compile things using the instructions in the dsl book and i was able to compile zile, but i haven't been able to compile anything more complex so i can't imagine how a package manager would. obviously other people are able to.

[blinkkin]

for general use i like what tc has, which is a very lightweight manager that doesn't require compiletc. perhaps it could include a compile feature (inactive) and then integrate with compiletc if compiletc is found. otherwise, it would download from the binary repository as usual.

I'm not speaking about changing TCL, for end user it'll be same as now. I would like better platform for making extensions. Right now there is no *.tce or *.tcz format of some apps I need for running my TCL.

Few days ago I was compiling wmii, which depends on libixp and dmenu. Newest version of wmii requried libixp from source repository, which is based on mercurial. So I downloaded code of mercurial and compile it. After that I obtained source code of libixp, which requried xlib for compiling. And so on...

As a example, with Source Mage it would be much easier - you need to type just "cast wmii" in console. This "package manager" know all dependencies and is using bash scripts like: "wget ... & configure & make & make install". After that I get binary ready to work on.

I would use extension if it was available, but right now for most apps only way is to compile them on your own. There're portable managers that could be used in TCL to save time of dev team. You see my point?

[tobiaus]

oh yeah, i would love to be able to compile things that easily. i mean i can think of a few things that i would compile right now: nice editor, moc, mp3blaster, qemu, i've requested most of them already.

i think there are reasons that compiling in tinycore maybe requires knowing more than in other distros, where it's just configure, make, make install (or something.) maybe it's the same. i like your idea though.

[Juanito]

i think there are reasons that compiling in tinycore maybe requires knowing more than in other distros, where it's just configure, make, make install (or something.) maybe it's the same. i like your idea though.

The only other distro I use use is yellowdog and believe me, it is a whole lot easier to compile something in tc than in a package management based distro where you never know what you will break by replacing/updating something in the dependency chain.

Although I no longer use dsl, even compiling in that was sometimes not obvious due to the (relatively) unknown origin of some of the base libs from knoppix.

Compiling in tinycore usually is just as easy as "configure, make, make install" and often when you're missing something in the base install, the missing item is already available as an extension - as an example, the gtk1/gtk2 libs are often required in order to compile software that depends on them and everything you need is already there as an extension.

You should give compiling in tc a go - it's not difficult and there are many people in the forum that would be glad to help.

[tobiaus]

You should give compiling in tc a go - it's not difficult and there are many people in the forum that would be glad to help.

i don't want to contradict you. this is something i really don't know much about, and besides i'd really prefer that you're right. however i've tried to compile several things, and only zile compiled, and when i asked for help there was a (very speedy, very polite) reply offering a link to a page on the lfs website that... to be honest, showed me just how beyond me compiling really is. most of the things i'm interested in compiling do not have fancy gui's, but ncurses seems to present just as much of a challenge.

[curaga]

The issue with a source-based package manager is that all packages have their quirks.
One that applies to all is the url / mirrors. Then package X might not compile with certain optimizations. Or package Y might install things in a non-wanted place with just "./configure".

So, it would require a bit more work, as to create a "recipe" one needs to actually do the compile. To use some other distro's recipes would mean not only being dependent on them, but also that we'd need to match their base and configuration. Otherwise we'd need to change their recipes, which possibly could not be automated.

[tobiaus]

in other words, instead of creating an extension, you'd have to create something like this:

readme
home.url the url of the project page
src.url the actual url of the source package
makeinstall.sh a wrapper script for make install
makescript.sh a wrapper script for make
configurescript.sh a wrapper script for configure

home.url and src.url could be multiline, but these would be as simple as any other tc system, they could be one url per line without other information, like a dep list.

you could call it ".tcs" it wouldn't require changing the getting started page, because it wouldn't be a "mode" for running tc, to make tc compile its extensions on each boot. it would simply be a third type of extension for people that want to create source based packages. it could become as popular as tce and tcz, but i believe it will play a supporting role.

sourcemage is a very cool distro. i've never used it but i like the idea. i tried to compile moc today. as usual it checked a lot of things, it got to configure or make and started telling me why it wasn't going to compile. .tcs files could be collected and used to create documentation and howtos for compiling like experts. it would be a feature that is still very rare in distros, very faithful to the idea of gnu and linux, and possibly help to give tc an even larger place in the world of distributions. but the first thing tc should be is simple. i'm hoping this is a very simple way to do what sourcemage does in tc.

[Jason W]

While we are not using a source based package manager, I do think we would benefit from having a build script for each package.  Not to mention the GPL requires it unless you are hosting the configured source.  They don't have to be overly complex or automatic though they can be.  You build and submit a package today, and say a year later you may be no longer around.  With a recipt/build script someone can easily update or recreate your package ir if needs updating or fixing.  Something as simple as this would make it easy to recreate your extension:

Code: [Select]

#!/bin/bash

# Needed dependencies: gtk1.tcel glib1.tcel openssh-0.9.8h.tcel
# Needed files: xmms-1.2.11.tar.gz xmms_doublesize.patch

export CFLAGS="-march=i486 -mtune=i686 -Os -pipe"
export PKG_CONFIG_PATH=/usr/lib/pkgconfig:/usr/local/lib/pkgconfig

tar xzvf xmms-1.2.11.tar.gz
cd xmms-1.2.11
patch -p1 < ../xmms_doublesize.patch
sed -i 's:-lXxf86vm::g' configure
./configure --prefix=/usr/local --disable-mikmod --disable-nls --enable-oss --disable-esd --disable-opengl --disable-alsatest

make
make DESTDIR=/mnt/hda2/pkg install
rm -r /mnt/hda2/pkg/usr/local/man
cd /mnt/hda2/pkg/
find . | xargs file | grep "executable" | grep ELF | grep "not stripped" | cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null
find . | xargs file | grep "shared object" | grep ELF | grep "not stripped" | cut -f 1 -d : | xargs strip -g 2> /dev/null

# create extension now, can automate if desired

It takes a few more minutes to make a script for each package but it saves time in the long run when you want to update it or have to rebuild it.  I had to rebuild my extensions a few months back for i486 compatibility and believe me, having a build script for each one saved me countless hours.

While on the subjuct, please do remember and send in a build script with GPL licensed extensions as we are required to have one along with the source.