Re: How to get package in main with the same version to upgrade over a mentors.debian.net version?
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:
----------------------------------
remco@seesink:~/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 <raseesink@hotpop.com>"
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 <raseesink@hotpop.com>"
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 <jeroen@wolffelaar.nl> 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
> Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357)
> http://Jeroen.A-Eskwadraat.nl
Reply to: