builder/uploader meta-info

[electrickery]

For packages that are build and uploaded by others than the package maintainer, there should be a channel to deliver some information to the end user. The simplest way I could think of given the current Deken functionality is adding another file with a standard name.

This is more a start of a discussion than a real proposal.

For this example the name is "DekenUpload.txt".

cat > DekenUpload.txt<<EOF
This creb package is downloaded from http://zwizwa.be/darcs/creb using 
"darcs get http://zwizwa.be/darcs/creb", build, packaged and uploaded to
http://puredata.info/Members/fjkraan/software/ at 2015-12-27. 

Apart from this file and the source package creb_source.tgz all files and directories are
the result of the make install command.

fjkraan@xs4all.nl, 2015-12-27
EOF

Adding build hardware info is also an option, or a list for all supported platforms.

[chr15m]

Interesting idea - it would be good if the file could have some structure to allow for parsing in the future.

[electrickery]

Somewhat inspired by the library meta-files it could look like this:

WEBSITE
LIBRARY
VERSION
RETRIEVE_DATE
UPLOADER
UPLOAD_SITE
UPLOAD_DATE 
REMARKS

[umlaeute]

Probably a format like Debian's control file is a good start (it's easier to write by humans than e.g. json, and sufficiently parseable by computers).

• Format - deken package format
• Package - library name
• Version - library version
• Description - one or more lines describing what the package does
• Homepage* - the official homepage of the library
• Source - an URI describing where the source was fetched from
• Date - when the source was retrieved
• Packager - name (+ optional email) of the deken maintainer
• Uploader* - name (+ optional email) of the one who prepared this upload if it's not the official maintainer
• Package-Date* - when the deken package was created
• Built-Using* - which tool-chain was used,...
• Comment* - additional notes

The field names are mostly taken from Debian.

My gut feeling tells me, that this information should be included in the package itself (rather than being distributed separately).
for future use i would just go and reserve an entire folder /_deken/(and use /_deken/control as the filename for this meta-info; this is more inspired by Debian than by the library-meta files)

I'm not sure about the original suggestion of UPLOAD_SITE and UPLOAD_DATE as this seems to be redundant information:

• the date can be tracked on the download-site
• if the user doesn't know the download-site, how are they supposed to retrieve the meta-information
  (note that here upload site and download site are used exchangeable).
• human-maintained redundant information often tends to diverge 😞

[electrickery]

The idea was to create a file containing download, build and upload info for existing packages. Like the creb package in the original example; I do not maintain it, and the maintainer has no intention to create deken packages for all platforms. Here a file containing 'post-package-maintenance' information seemed useful.