Re: Version to use in package for a program with non standard versioning
-----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 Folding@home client software on Unix systems
running KDE."
Stanfords Folding@Home 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 F@H client in Debian.
There is a Debian package by Nick Lewycky which installs the F@H 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-----
Reply to: