Early adopters can "ipkg install" it directly from:
http://scream.east.isi.edu/familiar/hacks/ipkg_0.9_arm.ipk
Otherwise, it will show up in the unstable feed shortly.
The big news is that it now supports multiple package source
repositories and it also allows you to retarget package installation
to other directories, (ie. ramfs, compact flash, or micro-drive).
The release notes, (at the end of this message), are horribly long,
but there are some good little bits in there, so read them some time
you are bored, (especially if you plan on maintaining any package or a
repository of packages).
Send me patches for the problems you hit. :)
-Carl
ipkg 0.9 Release Notes
======================
Summary
-------
New features (these are described in more detail later):
* Multiple package repositories are now supported.
* Package installation can now be easily retargeted to
multiple destinations.
* Custom support for Debian's update-alternatives system.
* A custom update-menus script for Debian's menu system.
New command-line options:
* -d or -dest can be used to choose a sub-tree for package
installation, removal, upgrade, etc.
* -force-depends turns dependency checks into warnings rather
than errors.
* -force-defaults prevents ipkg from prompting the user, (it
will just march forward as if the user chose the default
action at each prompt). This is designed to be used by
package management front-ends. (NOTE: This option does not
prevent package installation scripts from prompting the
user.)
Bug fixes:
* "ipkg upgrade" will no longer downgrade a package.
* ipkg no longer croaks if a Packages file contains two
different versions of the same package, (NOTE for repository
maintainers: it really *should* look at the one with the
highest version, but for now it simply uses the first one it
sees. Arrange your Packages files carefully or eliminate
duplicates altogether)
Gory Details
------------
NEW CONFIGURATION FILE FORMAT
The multiple source/destination support requires an incompatible
change in the /etc/ipkg.conf file. ipkg 0.9 includes a postinst script
that should convert your old /etc/ipkg.conf to the new format so you
shouldn't even notice, (but let me know if you have problems). The new
ipkg.conf format looks like this:
# Must have one or more source entries of the form:
#
# src <src-name> <source-url>
#
# and one or more destination entries of the form:
#
# dest <dest-name> <target-path>
#
# where <src-name> and <dest-names> are identifiers that
# should match [a-zA-Z0-9._-]+, <source-url> should be a
# URL that points to a directory containing a Familiar
# Packages file, and <target-path> should be a directory
# that exists on the target system.
src custom-package ftp://localhost/ipkg
src familiar-unstable
http://familiar.handhelds.org/familiar/feeds/unstable/packages/armv4l
dest root /
dest ram /mnt/ramfs
dest ext /mnt/hda
MULTIPLE PACKAGE REPOSITORY SOURCES
Multiple package repositories can be listed using any number of "src"
lines in /etc/ipkg.conf. The URL should point to a directory
containing a Packages file. Put your favorite sources first in the
file as ipkg will favor the first source listed if a package is
available from multiple sources.
You don't have to do anything special on the command-line to take
advantage of the multiple sources, it should just do the right thing.
MULTIPLE PACKAGE INSTALLATION DESTINATIONS
For multiple package installation destinations, list each one on its
own "dest" line in ipkg.conf. The <dest-name> that you choose can be
used with the -d or -dest option on the command-line to retarget
package installation to different directories. For example, assuming
these packages exist, you could do:
ipkg -d ram install emacs
ipkg -dest /mnt/hda install gimp
Note that you may install to an explicit directory, (rather than a
<dest-name>), as in the above command to install gimp, but this is
discouraged as ipkg won't be aware of this destination so things like
"ipkg status" and "ipkg remove" won't work for packages installed this
way, (unless the directory is listed on a "dest" line in
/etc/ipkg.conf)
I've tried to make the behavior of all commands as intuitive as
possible with regards to the multiple sources. The rule is that by
default most commands will act on all installed packages in all
destination directories. Adding the -d or -dest option restricts the
command to apply only to the specified directory. The one exception to
this rule is that "ipkg install" without a -d option will always
install a package to the first destination listed in /etc/ipkg.conf,
(rather than installing it to all destinations which would not be very
useful).
NOTE to package maintainers: Package installation scripts may now
examine the $PKG_ROOT variable to determine where the package was
installed. These scripts can then use this variable to fix things up
so that the package will still work from its new location -- perhaps
by making symlinks for files that the package requires to be in
absolute locations. For example:
[ "$PKG_ROOT" != "/" ] && ln -s $PKG_ROOT/etc/foo.conf
/etc/foo.conf
Packages should not try to fix up things such as the PATH variable or
registering library directories in /etc/ld.so.conf. These issues are
not package specific and can be handled on a one-time basis when the
package installation directory is created.
ALTERNATIVES SYSTEM SUPPORT
ipkg now supports the update-alternatives mechanism that Debian uses
to manage the fact that multiple packages provide alternate versions
of the same binary, (for example ash and bash both want to supply
/bin/sh).
Any package wanting to provide a file that is also provided by another
package should use update-alternatives to request a symlink, (and
should not include the file directly).
For example, ash wishes to provide /bin/sh which is also provided by
bash. So the ash package now does the following in postinst:
update-alternatives --install /bin/sh sh $PKG_ROOT/bin/ash 20
This registers /bin/ash as an alternative for the /bin/sh program
(registered as sh) with a priority of 20. The alternative system will
simply create a link for the alternative with the highest
priority. Establishing priorities will require some coordination
between maintainers, (please be reasonable -- numbers from 1-100 or so
should be fine). Debian has a list of several policy factors which
determine the correct priority, (ie. programs which register
themselves with the menu get some bonus priority points). We might
want to think about coming up with something similar for Familiar.
Also, the package should unregister itself at package removal
time. For example, ash does the following in prerm:
update-alternatives --remove sh $PKG_ROOT/bin/ash
Note that the update-alternatives script provided by ipkg is a custom
implementation, (a 4kB shell script compared to Debian's 21kB
binary). It doesn't support all the options of it's Debian
counterpart, (most notably the slave option is missing -- just call
update-alternatives multiple times instead). But packages using this
system should still be 100% compatible with dpkg, (you can thank me
later Tangent).
DEBIAN MENU SYSTEM SUPPORT
We've mentioned before that Familiar is using the Debian menu system
for registering packages with the system menu. What needs to be done
by packages is is documented here:
http://handhelds.org/~nelson/menu/
This release of ipkg now includes an update-menus script to be called
by package installation scripts.
The last thing needed for a complete menu system is that each program
foo that provides a menu, (ie. a window manager or program launcher),
should provide a script named /etc/menu-methods/foo that can read the
menu entries in /usr/lib/menu and create the appropriate menu files
for the program. (Note that these menu-method scripts will be slightly
different than Debian's as these will read /usr/lib/menu/* directly
rather than accepting menu entries on stdin. Also, ipkg does not
provide Debian's install-menu program which isn't worth its wait).
I believe that the foal application launcher already has this support.
Received on Wed Jun 13 2001 - 21:57:42 EDT
This archive was generated by hypermail 2.2.0 : Mon Jul 25 2005 - 17:12:27 EDT