IPK 1.1 Spec
Jan Niklas Hasse
I've read through the specs here
(http://listaller.nlinux.org/wiki/doku.php/ipk1.1-specification-draft)
and it's really good already, but I got some questions/suggestions.
1. Why do we need the fileinfo.id file? I think it would be better if
files are already in the right directories inside data.tar.xz. AFAIK
this is also how .deb files work.
2. DSupport should be dropped IMHO. The goal should be to support all
distros, the creator of the package should not try for himself every
distro out there and list them. Instead we could introduce a blacklist
(DistrosNotSupported), but I don't think that's even needed (it should
simply work everywhere).
3. Dependencies should be handled differently. I will post a detailed
draft of this soon (I talked about this a while ago IIRC).
4. Instead of creating a MD5 sum of every file, I would simply create
one MD5 sum for the data.tar.xz (or the .ipk file itself). Imagine a
package contains 1,000,000 small files (< 10 bytes each). Simply the
MD5 sums stored in the fileinfo.id file would consume more space then
the files their-self. Also it's more complicated to check every single
file (and CPU consuming).
5. I would rename arcinfo.pin. What does arc stand for? (Archive I
guess, but it might not be obvious for everyone). What does pin stand
for?
6. The architecture shouldn't be a part of the filename because this
only confuses users. Also we should advertise using architecture
independent packages ;)
7. Maybe use SHA1 instead of MD5. Don't know about this. But I hear
they are more awesome ;)
Okay that's all for now, I hope I wasn't to harsh :)
Regards,
Jan
Matthias Klumpp
> I've read through the specs here
> (http://listaller.nlinux.org/wiki/doku.php/ipk1.1-specification-draft)
> and it's really good already, but I got some questions/suggestions.
>
> 1. Why do we need the fileinfo.id file? I think it would be better if
> files are already in the right directories inside data.tar.xz. AFAIK
> this is also how .deb files work.
I'm already planning this to make the fileinfo-file obsolete. But this
feature requires a lot of changes on the current installation functions, so
it hasn't appeared in the specs yet.
> 2. DSupport should be dropped IMHO. The goal should be to support all
> distros, the creator of the package should not try for himself every
> distro out there and list them. Instead we could introduce a blacklist
> (DistrosNotSupported), but I don't think that's even needed (it should
> simply work everywhere).
It should, but devs should also have an option to display warning messages
(not tested on this distro etc.)
Also, IPK DLink packages still need this key.
> 3. Dependencies should be handled differently. I will post a detailed
> draft of this soon (I talked about this a while ago IIRC).
Nice, this point really needs a lot of work. The current solutions really
suck.
> 4. Instead of creating a MD5 sum of every file, I would simply create
> one MD5 sum for the data.tar.xz (or the .ipk file itself). Imagine a
> package contains 1,000,000 small files (< 10 bytes each). Simply the
> MD5 sums stored in the fileinfo.id file would consume more space then
> the files their-self. Also it's more complicated to check every single
> file (and CPU consuming).
For updates Listaller needs to know a checksum of each file to determine
if an update is needed. So we need to store MD5Sums somewhere.
We also need to make clear which files belong to the IPK package and which
not, which files are configuration and which normal data. For all this
stuff we need the checksums and some special flags for each file. To avoid
doubling the information, I plan to put all this (filename, md5sum, flags)
into one new file.
> 5. I would rename arcinfo.pin. What does arc stand for? (Archive I
> guess, but it might not be obvious for everyone). What does pin stand
> for?
This is a relict from IPK 0.1 (those files were simple ZIP archives)
"arcinfo" means archive information and "pin" is "package information".
All files in old IPK layouts had the pin extension. (If they were included
by another pin file, the extension was "id")
We could rename the "arcinfo.pin" to "control". Debian devs will feel at
home :P
> 6. The architecture shouldn't be a part of the filename because this
> only confuses users. Also we should advertise using architecture
> independent packages ;)
Architecture is to checkout if the pkg works on the current platform
without opening the IPK - but if we have multiarch IPKs, this is - of
course - no longer useful and necessary.
> 7. Maybe use SHA1 instead of MD5. Don't know about this. But I hear
> they are more awesome ;)
This is also planned, but it's on my list of "not really important
features". SHA1 is a little bit more secure than MD5. (But we already sign
IPKs, so security is no problem)
> Okay that's all for now, I hope I wasn't to harsh :)
No, keep on commenting this stuff. As more people criticize it as better
can it become.
Regards
Matthias