Yes, and it works too :)
I know one of the FAQs will be "Why did you start from scratch?". The
answer is that I found existing package managers for Linux to be quite
demanding, and they undoubtedly have dozens of features that a large
distribution finds essential, but that are pointless on the OSD.
There is a good little package manager that is used by some handheld
Linux distros... it is called ipkg. All was looking great, until I
downloaded the source and found it to be written in Python :(
lpkg supports fetching feeds and packages from the file system, HTTP
and FTP(untested). It also supports dependencies, etc.
There are still some things to finish/add, but it should be quite usable.
Installation instructions:
Grab http://matthewwild.co.uk/projects/Neuros/lpkg/lpkg.lpkg
Make a directory somewhere on your OSD, on something that will stay
attached (ie. memory card, USB drive). All packages will be downloaded
and installed under this directory. My directory for example is
/media/USB/osdroot
Move lpkg.lpkg into this directory
tar xf lpkg.lpkg
. ./setup.sh (The 2 dots at the front, with a space between, are important)
How to use:
lpkg (should give you a list of commands)
lpkg addfeed http://matthewwild.co.uk/projects/Neuros/packages.lpf
lpkg update (will refresh what it knows about packages from all added feeds)
lpkg list (will list all packages it knows about)
lpkg install wooble (will install the latest version of the web
interface, I'll post more on this seperately though)
lpkg update && lpkg upgrade; should keep you up to date as new
versions are released.
Next time you log into your OSD again, you need to cd
/path/to/your/osdroot and run setup.sh (the same way as described
above). This is because it needs to set some environment variables for
lpkg to work. Hopefully this will not be necessary in the future.
On the way is an lpkg module for the web interface, and a Qt GUI
frontend for the new firmware.
For developers:
Building packages is easy, and more so with a helper script I made:
http://matthewwild.co.uk/projects/Neuros/buildpackages.lua
That script reads a file, packages.info, from the current directory.
Mine (for an example) can be found here:
http://matthewwild.co.uk/projects/Neuros/packages.info
The script will generate an .lpkg file for each package you define,
and an index.lpf (a feed used to hold package metadata).
The packages must be on the same server as the feed, and using the
same protocol (ie. HTTP). This is for a little security. Feeds
pointing to packages on an external host will be allowed once I
complete MD5 checking of package files.
Questions, comments, bug reports, right this way please!
Matthew
(I will re-post this message in the forums.)
I have just looked inside but not tried it yet, but from the
specifications it seems a nice work.
I assume the binaries are installed in a card of your choice, so the
applications need to be tailored to be able to run from there, which
is ok as long as the apps don't assume unhealthy things.
However using this to install new libraries can be an issue, unless we
add as part of the library search path this removable path where the
package manager installs to.
> Next time you log into your OSD again, you need to cd
> /path/to/your/osdroot and run setup.sh (the same way as described
> above). This is because it needs to set some environment variables for
> lpkg to work. Hopefully this will not be necessary in the future.
Or you can add this to your user-defined login script
/mnt/OSD/rc.local (if I recall correctly)
> On the way is an lpkg module for the web interface, and a Qt GUI frontend for the new firmware.
This would be extremely nice, especially the GUI frontend.
> Building packages is easy, and more so with a helper script I made:
> http://matthewwild.co.uk/projects/Neuros/buildpackages.lua
This is another point that is pretty important. The more it's easy for
people to build packages and publish their "feeds", the more likely
this is to be picked up and included.
> Questions, comments, bug reports, right this way please!
I'll give this a shot during the week.
But mostly I want to say that the more people start to comment on
this, use this, fix this and generally give feedback on this, the more
it is likely to get included in the new software main tree at some
point.
Matt, if you can think of what we (as in Neuros) can do to make it
easier for people to run this package manager independently from the
official distribution, please let me know.
There are good chances it will make it into the official distribution
after we release the new line officially, but right now the best
course of action i think is letting you, finish it up and get it
really stable with the help of community.
Thanks,
--
nero
Installed apps are located in the directory of your choice, but it
must be read/write, and available for as long as you want to use the
packaged applications. nerochiaro mentioned an idea about utilising
AZ's CF card for this, in a separate partition, I think.
This way they won't get overwritten when you update firmware (the
package manager will update them separately).
> Given the read only filesystem how does it update the configurations?
It also stores some configuration in /mnt/OSD, so it can find itself,
wherever you first put it.
> I'm sure these questions are package manager 101, but it would help me
> to know the answer as regrettably I'm often the one doing the first
> level pitch to developers on this stuff, so it would be a great help
> for me to understand this a bit, since it seems central to managing
> 3rd party apps.
Not obvious at all, since the read-only file system does make things a
little more tricky than usual. Basically the package manager creates a
new directory, and all the applications are installed under there,
instead of / (the root, read-only, system). There are some occasions
when an application may insist on looking in the real filesystem root
instead (ie. to load libraries) but nerochiaro has a solution for that
too :)
Matthew.