-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Neil Williams wrote: > I'm not claiming to have an authoritative answer for all this, I'm not a DD > yet.
Don't worry, I appreciate all feedback. But I would like to know what a DD has to say about this. > Why is it in contrib then? Just curious really. If I look at what the Policy has to say about contrib: "Examples of packages which would be included in contrib are: * free packages which require contrib, non-free packages or packages which are not in our archive at all for compilation or execution, and * wrapper packages or other sorts of free accessories for non-free programs." I think the first is the case, since kfolding "is an applet for the KDE panel. It provides a convenient and unobtrusive way to monitor, visualise, and control the [EMAIL PROTECTED] client software on Unix systems running KDE." Stanfords [EMAIL PROTECTED] client is not DFSG-free. Stanford won't release the source, and you need permission if you wish to write for a 3th party installer and no one is allowed to distribute the software. AFAIK, thats the reason why there's no [EMAIL PROTECTED] client in Debian. There is a Debian package by Nick Lewycky which installs the [EMAIL PROTECTED] client on Debian though. http://wagon.dhs.org/folding/ >>As I said, one time there are a few updates in one week, sometimes even >>multiple updates on one day, although those are rare. Usually there are >>one or two updates in one month, other times there are no update for a >>whole month or more. > > Is there really any point in incrementing the version that often? Are the > upgrades incompatible in any way? I don't know any Debian packages that need > to change this often. It can take several days for a release to propagate > through the various uploading systems, especially new binaries. Personally, > I'd expect a monthly release at most and if users need updates in between, > they'll have to be downloaded separately. Don't know how easy that would be > to configure though. > :-( I don't think the way qd works with qdinfo.dat differs much from an AV for instance. Take this scenario for example: I've released qd-1.1.0 and qdinfo-20061226 not so long ago. Now Stanford updates their project info, and qdinfo is updated. I release the new qdinfo package qdinfo-20061230, since there is no new release required for qd, this is al there is. A few days from now while working on qd I find a bug, I fix it and prepare a new qd package. I release qd-1.1.1 and qdinfo-20061230-1. The only thing changed in the qdinfo package is the latest functional revision of qd. The only thing which needs to be updated frequently is the qdinfo package, just like the clamav-data package with the ClamAV virus definitions in volatile. Another option besides using volatile for the qdinfo package, a cronjob could also be setup to simply download the qdinfo.dat each night. The only thing which could happen is that the user gets a notice when he runs qd that the version of qd he is using is older than the latest release available, because the qdinfo.dat has a higher functional revision in it. The notice is a bit annoying but it doesn't affect qd in any way, unlike the clamav-freshclam situation where you can have changes in the database format. > 1.1.0 may be more suitable then. > > The 1.0.0 version on the existing Debian package is important because unless > you increment from that point, apt may not replace the old package with the > new. I already thought apt/dpkg would not like it if I used my own versioning. Thanks for the confirmation. Another thing I was thinking for the qd version, would be qd-1.1.033. This would use the 1.1.0 version increase which is a good enough distinction between the previous version, but also uses the functional revision in the Debian package version. This makes it easier for myself and the users of qd to match de Debian version of qd against the normal release. Regards, Bas - -- GnuPG: 0x77A975AD -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDtZklRWRRA3epda0RAtRCAJwKaXuJItCTyUB1PoY9cPd4+fQZZACfXexx IexVmFcBD0y/0neCX+9hE6U= =1keV -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
