Feed Package File

[dz]

Ok, so I am working on the "Feed Update" feature of the ZSI2 and I just realized something.  The format for the "Package" file in feeds isn't very good.  In fact, it kinda sucks if you ask me.  I'm a programmer, so I do my best to get things done efficiently.  I really think it is super sloppy the way the Package file is laid out.

For those who don't know, this is the current format:

Code: [Select]

Package: package1
Priority: optional
Section: Misc
Version: 1.02
Architecture: arm
Maintainer: bob (bob@aol.com)
Filename: package1.ipk
Size: 457689
MD5Sum: 8175c563ab044f18b90d3324599643c8
Description: This is a game that rocks.
Then a new line, and the same code over and over.  Although this might work, I don't think it's a very good idea.  What if we want more than one line for the package description?  What if we want more than one line for anything?  

XML has been tried and it works great.  Many programs have built in support for it and I really think we should adopt it for the new package managers.  I propose the following format:

Code: [Select]

    Package1
    Optional
    

Misc

    1.02
    arm
    Bob (bob@aol.com)
    package1.ipk
    457689
    8175c563ab044f18b90d3324599643c8
    This is a game that rocks.


It's simple, easy to read, and it will be universally supported.  Everything in between the project tags is tabbed over; I just can't get this bbs to display it right.  It's also super-easy to add a new field if we want.

I apologize if this is already implemented, but if it isn't I ask that we start to try to.  The ZSI will support the old file format and as well I will have it start outputting data in XML format.  I think we should try and focus away from the old format though.

Any other developers want to give me their take on this?  I don't mean to step on anyones toes here, but I'm just trying to find a way to make this efficient.

[tumnus]

Er, you can have multiple lines for the description. I don't see why you would want multiple lines for any other field. Each entry is separated by a blank line. For example look here:

http://www.zaurususergroup.com/feed/Packages

XML is fine for robustness, but the ZUG feed packages file is already 172kb and that would take a lot of processing (relative to a Zaurus) if it was in XML. It wouldn't be universal since most people still use Sharp ROMs, which will only ever use the current feed format.

There's also a howto and script for generating feed indexes:

http://www.zaurususergroup.com/modules.php...20Up%20A%20Feed

This format has worked fine for 3 years now. Never heard of any real problems with feed indexes. So if it ain't broke....

[dz]

Ahh yes, I didn't notice the multiline ability.  I stand corrected on that point.  I still don't agree that it is a good format though.  Ya, it's been working for 3 years, but that doesn't make it right.  It just means it's the format that's been dealt with.

Just out of curiosity, what fields does the Package Manager read?  I've noticed some package listings have fields that others dont.  Is there a set standard that all package managers read, and if so, what's done with the other fields?  Cause if they're not really touched by the package manager and the size of the file might become an issue, it makes no sense in keeping them there.

[stupkid]

dz,

The fields in the Packages file are extracted from the control file in the ipk.  You can have multiline Package descriptions.  For example this is a perfectly valid control file:

Summary: A GNU collection of binary utilities.
Package: binutils
Priority: optional
Architecture: arm
Version: 2.15-1
Release:
Maintainer: Takuya Murakami <tmurakam@mtd.biglobe.ne.jp
Section: system
Size: 1304k
Depends:
License: GPL
Filename: binutils_2.15-1_arm.ipk
Size: 543032
MD5Sum: 0ec8b523e7d04d6bdd2f6d302aff64f4
Description: A GNU collection of binary utilities.
 Binutils is a collection of binary utilities. This package includes
 gprof, nm, readelf, size, strings, and strip only.
 (Not includes ar, as, ld, objcopy, objdump, ranlib, addr2line.)

As Tumnus has stated there are reasons why XML was not chosen for the Zaurus package manager.   What problem is exactly fixed by using XML?  I can see problems that will be introduced using XML, but I'm not seeing the upside.

The package format is derived from the Debian Package format, which is more flexible and useful then any other UNIX Package format.  You might want to check out the Debian Developer's Reference for more information:

http://www.debian.org/doc/developers-reference/

There are only a few fields that are actually required by the package manager in the control file.  The rest are gravy and you can even make up your own.  For example, you could add a feild "Coolness: very"  If you wanted to.  The Package tool will ignore this field, but maybe this is a field that some script will use or it is of some use to the user.

I use the following scripts, which I think are from the Zaurus Developers Site and one that I wrote quick and dirty (ipkg-expand).

Hope this helps.

[dz]

I understand now.  Well than, I'm sorry for getting a fuss about nothing.  I suppose it was all due to my lack of understand of the format :-/

Regardless, I think I will still have the ZSI update the feeds using the current format as well as give out an XML file.  That way the extra format is there incase anyone wants to use that, as well as obviously keeping the old format.

Sorry

[stupkid]

Hey dz,

You may want to use the control file to your advantage.  You could use a parameter to determine the ROM that the package was built for.  i.e.

ROMType: OpenZaurus (>= 3.5)

Or something like that.  Just a thought, but there would need to be a way of retro-fitting old packages.