[RFC] gnuwin32/kde-windows package format

Andreas Pakulat apaku at gmx.de
Thu Jan 3 23:28:53 CET 2008


On 02.01.08 20:44:24, Saro Engels wrote:
> II.2. The .mft file should contain a list of all files (relative path) 
> which are contained in the package, then one space character and then 
> the md5 sum of the file. This is the opposite of the output of md5sum.

As Michael already said I don't quite understand the why for this
difference.

> The .mft file, the .ver file and the .cmd file do not need a md5 sum and 
> get appended to the original list.

Why not? Also above it was said that manifest only has .mft and .ver

> II.3. In the first line of the .ver file there has to be the name of the 
> package, followed by a space and the version of the package, followed by 
> a space or a colon and a space and one out of 'Binaries', 'Developer 
> Files', 'Documentation' or 'Sources'. The case of those tags should be 
> ignored. If present, the second line starts again with the packagename, 
> optionally followed by a colon, followed by a space character and 
> followed by the description of the package (within that line).

Hmm, how about making this a bit more sophisticated and a bit more clear
what what is?

I propose to have:

.files with the list of files + md5sums for everything that is in the
package except the .files file itself.

.desc with the following format:
Name: <packagename>
Version: <version>
Type: <type>
Dependecies: <list of package names and eventually version information>
Optional Dependecies: <same as above
Size: <package size>
Installed-Size: <installed size>
Description: <onelinedesc>.

<start of multi-line-description>

For the list of packages I'm thinking about something similar as Debian
uses, i.e. foo ( >= 1.4.2 ) with >,<,==,>=,<=

This format is far easier to parse and to extend than putting everything
into the same line. 

Another thing to consider are windows-package-specific versions, we
might want to package the same source version of a package multiple
times. This could go into the releasetag, but I think there should be a
definition for our windows-specific versions of the packages so we don't
have to jump through hoops when parsing it (like checking wether its a
number, or a data or ...) And if its a specified number-format we can
more easily include it in the dependecy list.

> III.1. If needed, the manifest directory should contain a file following 
> the above mentioned naming scheme with the extension '.cmd' .
> This file should be called after installation and should be a normal 
> windows cmd.exe batch file.
> The file shouldn't need any parameters for execution - it is required to 
> run it in the installation directory though.
> if the file is C:\kde\manifest\package-0.1.0-bin.cmd, it should be run 
> in C:\kde.

As (IIRC) Ralf said: Its probably needed to have
pre-inst,pre-remove,post-inst and post-remove scripts. About the
parameters, I'm not sure mostly because I don't really know what a
package might want to do in that script and particularly what it might
need to do differently between an upgrade and a normal remove. Debian
packages have a distinction between being removed from the system or
being removed and then a newer version being installed.

I also think that in the long term signing the packages would be a good
idea. The metadata from the .desc file can be used to create a remote
repository of packages with a package list quite easily. That way the
installer can provide useful help like telling the user there's not
enough space :)

Andreas

-- 
You will obey or molten silver will be poured into your ears.



More information about the Kde-windows mailing list