[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