[gentoo-embedded] embedded package manager (was: hardened uclibc gentoo stages)

[Natanael Copa]

On Mon, 23 Aug 2004 20:30:41 -0400
Ned Ludd <solar@g.o> wrote:

> On Mon, 2004-08-23 at 16:36, Natanael Copa wrote:
> > On Mon, 23 Aug 2004 01:32:20 -0400
> > Ned Ludd <solar@g.o> wrote:
> >
> > > On Sat, 2004-08-21 at 03:12, Natanael Copa wrote:
> > > > I think I finally got some time to continue with my uclibc
> > > > gentoo project.
> > > >
> > > > As I understood it, its easiest to strat from scratch when using
> > > > hardened. Is there any place I can get uclibc hardened stages to
> > > > get started?
> > >
> > > The first generation stages were hardened ones.
> > >
> > > http://oc12.net/~solar/uclibc/gentoo/x86/packages
> > > Lots of fixes have happened from this time.
> >
> > I browsed the dirs and found somehting called ipkg. What is that?
>
> It's WiKi page needs to be updated but..
> http://handhelds.org/moin/moin.cgi/Ipkg
>
> It's something I'm testing out while in the search of an ideal way of
> embedded package management. I learned about it via the OpenWrt
> project( http://openwrt.org ) which I also have an active interest in.
> There is no ebuild for it at this time.

It looks really interesting! We were talking about dpkg, but it is
designed to run on disks.
 
> Compact Flash Sub Package Management is something that has yet to
> really be decided and or discussed in any meaningful manor..
> It's can go any direction that _we_ the community need/want it to go.
>
> This much is assumed.
> We want to use the portage system as our package building system.
> We don't want (perl|bash) scripts/(man|info|doc)-pages.

Agree!

> *.a, *.la  and *.h files will be handled by another FEATURE= somewhere
> else down the line probably in ebuild.sh so it's transparent to the
> packages themselves.

Sounds good!
 
> But we have some questions.
> Do we want to remove these from packages when they are still in
> .tbz2 format?

I think it would be nice to have the possibility to choose.

> Do we want to use (gzip|bzip2) compression for the packages
> themselves?

I shouldn't be impossible to handle both compressed and uncompressed?

> Is complying to busybox only commands a must?

It would be nice, but, on the other hand, if we uses normal archives,
like tar/tar.gz/tar.bz2 it could be possible to unpack the packages with
busybox only commands. In bering it is possible to tar -zxf package.lrp
and there you go. In theory, that is possible with tbz2 too.

To update/remove it is not that important.

> What must the package management do?

As said, a minimal, simple extractor is good.

I would like simple runtime dependency handling. Something like:

pkg_install() {
	# chek if it needs to be downloaded etc..
	$UNPACK $PKGSRC/$1.pkg
	source $1.metadata
	for i in $DEPENDENCIES ; do
		pkg_install $i
	done
}

Upgrade packages on the fly without needing to reboot.

In case of a read-only media, somewhere to save local configs. we
currently run from CD-ROM and store the configs on floppy. It would be
nice to store local configuration anywhere (usb stick, network mount)

pre/post-install/update/remove scripts. It would be nice to be able to
write a small script that is included in the package to be able to run
some code when installing/removing packages.

In our current apkg I was thinking of a /var/lib/lrpkg/<package>.scripts
that was sourced. This could contain a

{pre,post}_{install,update,remove} script that is run.

For example:

post_update() {
	/etc/init.d/service restart
}

pre_remove() {
	# backup our private info before removing.
	cp /some/data /some/where
}


> Fetch remote files and install t

yes, that would be great! At least, it should not be designed to be
impossible to have that feature in future.

> Clearly many packages will want behavior of a read-write system so
> should we patch programs to behave on read-only systems?

That would need alot of work, right? symblinks? We could have some
policies where it could be possible to have read-only data, like /etc
/bin /sbin/ /usr /opt /lib, while there are some places where the rw dat
could go, like /var /tmp.

ln -s /etc/mtab /var/lib/mtab

> Should we use the /tmp dir at all or stick strictly to /dev/shm/ for
> security reasons?

I have not studied the problems with /tmp enough. Do you have any links
about this subject?

> Do we just want to use the tbz2 and write a simple emerge.sh which
> handles the lowest of level functions.

Maybe. Is there any documentation on this tbz2 format? I have not used
it much. (there is a reason I choosed a source based distro :)
 
> Arghh.. I wish I/we could take an easy poll on our website.
>
> So many options.. Input needed..

I have not really studied how the ebuild scripts work, but what about
modularized package managers?

PKG_MANAGER=ipkg ebuild foo.ebuild package
PKG_MANAGER=dpkg ebuild foo.ebuild package
PKG_MANAGER=rpm ebuild foo.ebuild package
PKG_MANAGER=tbz2 ebuild foo.ebuild package

ebuild will look for a 
/usr/lib/portage/pkgmanagers/${PKG_MANAGER}.sh

In every package manager you will need to have some func, like create,
install, remove etc. That way it could be easy to write your own package
manager for your own runtime packages, that handles read-only patching,
stripping *.a, *.la and *.h, compress with bzip2/gzip if wanted.

That is just some ideas.

-- 
Natanael Copa

--
gentoo-embedded@g.o mailing list