Re: one binary package created by different source packages, will the old source package disappear?
Jeroen van Wolffelaar <jeroen@wolffelaar.nl> wrote:
> N.B.: Such questions are easier to answer (less guessing needed w.r.t.
> missing information) given a real example.
I've noticed that. I thought it was a simple question regarding the
infrastructure setup, but it turns out not to be...
"foo" in reality is tetex-bin, and last autumn we created a
stripped-down version of the tetex-bin_2.0.2 source package which only
builds the old binary packages libkpathsea3 and libkpathsea-dev. "foo2"
is tetex-bin_3.0 with binary packages tetex-bin, libkpathsea4 and
libkpathsea4-dev.
> On Mon, Mar 20, 2006 at 12:03:13PM +0100, Frank Küster wrote:
>> Hi,
>>
>> assume the following scenario:
>>
>> - Source package foo creates binary packages libfoo1 and libfoo-dev
>> - source package foo2 creates binary packages libfoo2 and libfoo2-dev
>>
>> Since both versions are API-compatible, libfoo2-dev is renamed to
>> foo-dev, replacing the old binary package from source package foo. Will
>> the complete source package foo have to disappear, or will foo and the
>> binary package libfoo1 continue to be available?
>
> If foo2 didn't exist yet, you'd most likely want to start your
> transition by having a new 'foo' instead, creating libfoo2 and
> libfoo-dev. (ABI/SONAME change, but no API change, so -dev remains named
> the same).
Back then, we decided against that solution, because we wanted the new
upstream tetex (especially the tetex-bin package) to be able to migrate
to testing without initiating an other library transition (which was
forbidden back then).
> If foo2 already exists, I'd still go for that solution, but you'll then
> need to ask for foo2 removal via a bug to ftp.debian.org.
That's not possible, I think, unfortunately - we don't want teTeX which
currently provides libkpathsea4 in a source package named foo, err,
libkpathsea3.
We now have tetex-bin_3.0*, libkpathsea4_3.0* and libkpathsea4-dev_3.0
in testing and would like to get rid of libkpathsea3. In order to make
that easier, it was suggested to rename libkpathsea4-dev to
libkpathsea-dev and request binNMUs of the affected packages. However,
I was concerned whether that would make the libkpathsea3 binary package
disappear, and make all package uninstallable.
> Because there is API compatibility, I'm assuming here it makes not much
> sense to keep both libraries in at the same time. If you want to keep
> libfoo1 available (would need a somewhat decent reason, ideally),
Just as long as there are still packages that link against it.
> you'll
> need separate source package names (indeed foo2 then), and will need to
> make a new upload of 'foo' stopping to provide a -dev package.
> Otherwise, ít'll be impossible to do security uploads without making
> those changes at that time -- however, libfoo1 will remain available,
> even lacking such upload.
So I guess it would be acceptable to leave the old packages as they are,
wait until all packages have been recompiled and migrated to testing,
and then request removal of the libkpathsea3 binary package?
Regards, Frank
--
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)
Reply to: