Dear Gauthier and Eric, I'm working on the RFP for vle filed by Gauthier [1] on Debian bug tracking system (BTS), I checked your software and I have some interest on it (I'll write to you about this later) so I changed your RFP into a ITP some time ago, and I'm planning to maintain it under DebianScience [2] as it looks to me like a good candidate for this team... [1] http://bugs.debian.org/485985 [2] http://wiki.debian.org/DebianScience OK, I have some questions for you: debian/copyright ================ You reported 'Lucent Technologies' as copyrigth holder for some functions in CSVReader.hpp, but you didn't include the license for this code... Are you sure this code is available under a free software license? If yes, please include the license statement granted by Lucent in the sources; if not, please replace this code with a free equivalent. vle-0.6.0/vle/data/CSVReader.hpp: * @brief Copyright (C) 1999 Lucent Technologies * Excepted from 'The Practice of Programming' * by Brian W. Kernighan and Rob Pike sonames :S ========== I have been following (and packaging) your sources since I saw the ITP (v0.5.0) so I noted a soname change from 0 (on v0.5.2) to 0.6 (on current version)... I hope you are no trying to change your soname schema to follow release versions... Was this soname bump necesary? (declaration changes? struct changes?, functions semantics changes?)... I tried to check in your ChangeLog but (BTW) the file is empty. In any case, usually is my task to ask [4]: "have you already read the libtool manual?" but you are using cmake... so: do you fully understand hoe to manage the shared library process associated? :) [4] http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#sonameapiabi We are not expecting a lot of packages depending on your libraries, but if you try to change the soname in every release, we will need to generate new names for the binary packages on every release... and maintain a lot of Replaces... Conflicts... For now, I'm packaging all your libraries in a single libvle0 package (and its corresponding libvle-dev)... but I need to confirm how will you be managing the sonames... debian/watch ============ This file is used by DEHS [3] to monitorig new releases from upstream (you) awaiting to be packaged. [3] http://dehs.alioth.debian.org/ I need to define a regexp to track the released versions... Until 0.5.2, it seems like you were using the following format in SF: vle-*.tar.gz In this case, I just added some mangling for the release-candidates (we use the symbol '~' for this: 0.5.0~rc1 < 0.5.0, but 0.5.0-rc1 > 0.5.0). Until now my regexp was: opts="uversionmangle=s/-rc/~rc/" \ http://sf.net/vle/vle-(.+)\.tar\.gz And it was detecting the following versions in SF: 0.1, 0.2.0, 0.3.0, 0.3.1, 0.4.0, 0.4.1, 0.5.0-rc1, 0.5.0-rc2, 0.5.0-rc3, 0.5.0, 0.5.1, 0.5.2... But in v0.6.0 series you added some other suffixes, so now I found too: 0.6.0-Linux-i686, 0.6.0-rc1-sources, 0.6.0-rc2-sources, 0.6.0-rc3-Linux-i686, 0.6.0-rc3-sources, 0.6.0-sources... You did't released a '0.6.0.tar.gz', but anyway, after the rc mangling, a 0.6.0 version will be detected as: 0.6.0-rc* < 0.6.0 < 0.6.0-sources < 0.6.0-Linux-i686.... Sure, I can add more mangling for the new suffixes... Or, if you are planning to continue using the current format, I can change my regexp to search for: vle-*-sources.tar.gz In this case just 0.6.0-rc*, 0.6.0 and future releases will be detected... Anyway... is always better to define a filename convention with you :) So, may I suggest you to continue releasing just as vle-*.tar.gz, without another suffixes, except for the used on release candidates? Finally, I'm a little concerned about your 'Linux-i686' suffix... if vle is accepted on Debian, we will (try to) prepare this package for many archs, not just i686... and is possible that it will be prepared for another OS too (freebsd, hurd), not just linux... So.. Is this suffix really relevant? Is your code arch-specific? :S Thanks a lot! and have a happy new year! Ruben Molina
Attachment:
signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente