[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ok, i screwed up



Anthony Towns <aj@azure.humbug.org.au> writes:

> PLEASE DON'T INTRODUCE NEW PACKAGE NAMES GRATUITOUSLY.

So it seemed to me that because of my previous mistake it wasn't
gratuitous.  Regardless, I'm happy to do whatever you think best,
provided it solves the problem.

I certainly do agree that it is a thing to be avoided; if my judgment
was off kilter in this case, thanks for correcting it.

I know the normal procedure, which is your (a), but in this case
because of the ABI change and the need to keep the old library working
for the sake of the other package, (b) would have been the right
thing.  But it's too late for that now, alas.

> Bumping the actual revision of the libfoo-dev package (and having
> libfoo2-dev) is only useful if the source API of the library changes
> significantly.

Yes, this was necessary in this case.  The source API, according to
upstream, has significantly changed in the new 0.7.0 release of
libofx. 

> Anyway, Thomas, I've rejected your pending uploads, please start
> again. 

Alas, I can't, because the mistaken upload of 0.7.0 under the name of
libofx still happened, and is still in the archive causing problems.

> (a) The last upload of libofx was buggy. Oh well, bugs happen, let's
>      move on.
> 
>      Upload libofx.dsc with libofx1.deb (and ideally lintian errors
>      fixed)
> 
>      Make sure any package that linked against the buggy libofx upload is
>      fixed ASAP. Make sure any packages that link with libofx get updated
>      to the new ABI RSN too.

There should be no links against the buggy libofx.  So this is the step.

> (b) The old libofx needs to be supported.
>      Upload libofx0.dsc with libofx0c102.deb and libofx0-dev
> 
>      Do (a), with less of a rush on "RSN".

Yes, this is still necessary.

So I want to be crystal clear, just so that I don't make a mistake.
I'll wait until I get confirmation from you.  But I'm a little
confused.  I always just use dpkg-buildpackage, which seems like the
right way to proceed.  You want:

source package libofx, binary packages libofx1 and libofx1-dev (in libs)
source package libofx0, binary packages libofx0c102 and libofx0-dev
  (in oldlibs)

Have I got that correct?




Reply to: