Hi all, Thank you all for the suggestions. I am uploading new firebird packages right now with this method: > or alternatively 1.0-0mentors1 (decrease debian-revision by > one, append a mentor-specific part).
I wanted to prevent confusion in main when debian revisions are missing, and to keep the changelog clean. I like to document all my mistakes on mentors and get a clean version in main when I am ready. In case you were wondering, the unsolved security bug is: #251458 Urgh. I just noticed it didn't upload the original source: ---------------------------------- [EMAIL PROTECTED]:~/packaging/firebird/uploaded$ dput mentors firebird_1.0.3-0mentors1_i386.changes Checking Signature on .changes gpg: Signature made Fri 04 Jun 2004 03:59:11 AM CEST using DSA key ID 954F5EC7 gpg: Good signature from "Remco Seesink <[EMAIL PROTECTED]>" Good signature on /mnt/data/remco/packaging/firebird/uploaded/firebird_1.0.3-0mentors1_i386.changes. Checking Signature on .dsc gpg: Signature made Fri 04 Jun 2004 03:59:05 AM CEST using DSA key ID 954F5EC7 gpg: Good signature from "Remco Seesink <[EMAIL PROTECTED]>" Good signature on /mnt/data/remco/packaging/firebird/uploaded/firebird_1.0.3-0mentors1.dsc. Enter passphrase for key '/home/remco/.ssh/id_rsa': firebird_1.0.3-0mentors1.dsc 100% 881 0.9KB/s 00:00 firebird_1.0.3-0mentors1.diff.gz 100% 1086KB 15.7KB/s 01:09 firebird-examples_1.0.3-0mentors1_i386.deb 100% 259KB 28.8KB/s 00:09 firebird-dev_1.0.3-0mentors1_i386.deb 100% 83KB 82.6KB/s 00:00 firebird-utils_1.0.3-0mentors1_i386.deb 100% 638KB 18.2KB/s 00:35 firebird-server-common_1.0.3-0mentors1_i386.deb 100% 468KB 18.7KB/s 00:25 libfirebird-c32_1.0.3-0mentors1_i386.deb 100% 667KB 16.7KB/s 00:40 libfirebird-s32_1.0.3-0mentors1_i386.deb 100% 142KB 35.4KB/s 00:04 libfirebird-c64_1.0.3-0mentors1_i386.deb 100% 667KB 17.1KB/s 00:39 libfirebird-s64_1.0.3-0mentors1_i386.deb 100% 142KB 35.4KB/s 00:04 firebird-c32-server_1.0.3-0mentors1_i386.deb 100% 180KB 44.9KB/s 00:04 firebird-s32-server_1.0.3-0mentors1_i386.deb 100% 833KB 16.0KB/s 00:52 firebird-c64-server_1.0.3-0mentors1_i386.deb 100% 180KB 45.0KB/s 00:04 firebird-s64-server_1.0.3-0mentors1_i386.deb 100% 833KB 16.0KB/s 00:52 firebird_1.0.3-0mentors1_i386.changes 100% 3423 3.3KB/s 00:00 Successfully uploaded packages. Not running dinstall. ----------------- The manpage of dput doesn't help me with that. Any suggestions how to get firebird_1.0.3.orig.tar.gz uploaded? Many thanks, Remco. On Thu, 3 Jun 2004 21:19:43 +0200 Jeroen van Wolffelaar <[EMAIL PROTECTED]> wrote: > On Thu, Jun 03, 2004 at 08:48:55PM +0200, Remco Seesink wrote: > > Hello, > > > > I am preparing an updated package with an unsolved security bug. > > I would like to upload it to mentors.debian.net, but when it > > gets uploaded to main it will have the same version number as the > > one on mentors. I would to know if there is a way to upload to > > mentors and be sure it gets upgraded when it enters main. > > > > I had this problem before, but now it is worse because of the security > > bug. > > > > I looked at the policy and the reverse problem seems to be solved > > by using epochs. An negative epoch is not the way right? And how do > > I apply an epoch? Yada complains when I try to put an Version: field > > somewhere. > > > > Is there an other way to do it without having to bump the debian version? > > Or is that exactly what I should do? > > The proper way is to simply not upload to mentors.d.n with 'official' > debian revision numbers. Assuming the offical version will be 1.0-1, use > for example 1.0-1~mentors1 (if mentors.d.n accepts ~ in version > numbers), or alternatively 1.0-0mentors1 (decrease debian-revision by > one, append a mentor-specific part). > > This way, there is never a clash, you can see from the version number > it's an unoffical version. > > Two alternative approaches: > - simply increment debian revision, and use -v appropriately, it doesn't > matter certain debian-revisions are never uploaded. Disadvantage: > changelog cluttering, usually people won't have those unofficial > intermediate versions, and the differences among those are not very > interesting usually. If you merge the topmost changelog entry every > time, you seemingly have gaps in version numbering according to > changelog, not very nice either. > - Don't care about m.d.n, simply have your fixed version uploaded with > the same version number. m.d.n is unoffical anyway, you in no way have > to take care of proper upgrade paths at all. Disadvantage: in > bugreports with reportbug, and for the user itself, it's hard to see > whether the user/reporter has an unoffical version, or the official > one. > > --Jeroen > > -- > Jeroen van Wolffelaar > [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) > http://Jeroen.A-Eskwadraat.nl
