Hello!
[Mon, 27 Jun 2005] Adeodato Simó wrote:
> When uploading a version coming from experimental, it is normally
> preferred to include in the .changes file all the changelog entries
> since the last upload to unstable. This way people can easily read all
> the changes, and bugs get properly closed as well.
Yes. I remembered only when I already had built the packages
and was looking at the changes file to check.
[Mon, 27 Jun 2005] Adeodato Simó wrote:
> At the end of this mail there is the same list processed with Lars
> Wirzenius' dd-list script [1] (which we will hopefully see some day
> integrated into devscripts). I think it's good to provide lists of
> packages in this format, since it's much more suitable for human
> consumption and people can easily find their packages; looking at the
> mail you sent to @packages.debian.org addresses [2], it's really
> difficult to find one's own packages...
>
> [1] http://liw.iki.fi/liw/download/dd-list
> [2] http://lists.debian.org/debian-qt-kde/2005/06/msg00297.html
Nice script. It should be pushed into devscripts. Sorry I didn't know
about it before.
> In this list, there are two separate sets of packages: those
> build-depending on libjack0.80.0-dev or libjack-dev (e.g., arts and
> ams, respectively), and those who get an indirect binary dependency on
> libjack0.80.0-0 via some other package (e.g., xmms-jackasyn via
> libjackasyn-dev). It is normally a good idea to file these bugs / send
> these mails in two stages, in order to have all the build-dependencies
> fixed first, and then go for the binary dependencies.
Those "accidential" and indirect dependencies are IMHO an error.
Especially in the case of xmms-jackasyn where jackasyn tries to _wrap_
libjack IIRC.
> About the list itself, gst-plugins is no longer in the archive, and my
> apt sources know nothing about bio2jack. But there are some missing
I found no way to restrict apt-cache to a single distribution -- apart
from running it in a chroot.
> packages as well: wine (build-depends on libjack0.80.0-dev,
> libwine-jack depends on libjack0.80.0-0), soundtracker, and swami.
There is no wine for powerpc ;-] So it doesn't show up in my rdepends.
That's a general problem.
> These two build-depend on libjack0.80.0-dev but their binary packages
> don't depend on libjack0.80.0-0 -- there may be a bug there, or the
> build-dependency is obsolete. In either case, they should be notified,
> since they'll FTBFS automatically when libjack0.80.0-dev gets removed
> from the archive.
Yes. Some applications dlload libjack0.80.0 only if it's there. Others
forget to add their directory of plugins to dh_shlibdep's path.
> Also, and though we maintainers are supposed to do the right thing,
> experience shows this is not always the case, so it's really best to
> have library maintainers provide detailed explanations as of how to
> proceed. From your mail [2], maintainers build-depending on
> libjack0.80.0-0 will know that they have to change such B-D to
> libjack0.100.0-dev, but there are not crystal clear instructions for
> those build-depending on libjack-dev (honest!): though anybody reading
> the mail would say, "s/libjack-dev/libjack0.100.0-dev/ in
> debian/control", I'd bet money that some maintainer will upload with
> debian/control unchanged "because libjack-dev is now provided by
> libjack0.100.0-dev and buildds will install it". And then get the
> package compiled against different -dev packages depending on the
> architecture (more on architectures later).
True. But that happens also if others upload packages (due to other
reasons) before I tell them.
> And as per the two stages
> mentioned above, packages not directly build-depending on libjack*-dev
> should get special handling as well, such as asking for rebuilds only
> when build-depencencies are fixed in _all_ architectures, or providing
> info about what versioned build-dependencies to use.
You can see the strangeness of these accidential dependencies in
considering that you'll have to b-d on libjackasyn-dev (>= something)
just because only that version is built against libjack0.100.0.
> Ah, architectures... I think it's been a really bad idea to start this
> transition without waiting for the package to have built successfully
> in all our arches. At the time being, ia64 and s390 have already
> failed to build jack-audio-connection-kit 0.100.0-2 (not the fault of
> your package, though), which means that each upload of depending
> packages will fail on those arches and buildd admins have to requeue
> by hand.
Yes. As said above I'd have to ask everyone to stop uploading before I
upload and tell them to upload after all arches have been built
jack-audio-connection-kit.
> And finally, this is IMHO a sufficiently big transition that
> debian-release should have been contacted in advance, for guidance and
> advice too. Perhaps the answer would have been "Sure, go ahead right
> now", but it could also have been "We're sorting out the bits for the
> C++ transition, let's hold this a few weeks, ok? Sorry for the
> inconvenience." Or even (this is not your case, and I'm only
> mentioning as a worst-case scenario): "Dude, you just f*cked up our
> timeline for the C++ transition".
Sure. The number has grown a lot since the last API change.
BTW: I fear that there will be more of these new JACK releases.
> LIST OF PACKAGES
Thanks for that!
[Tue, 28 Jun 2005] Hamish Moffatt wrote:
> On Mon, Jun 27, 2005 at 04:10:42PM +0200, Robert Jordens wrote:
> > I uploaded a new release of jack-audio-connection-kit to unstable. The
> > following source packages have been built against libjack0.80.0-dev and
> > must now be rebuilt against libjack0.100.0-dev due to incompatible API
> > changes. I plan to file important bugs and then upgrade them to
> > something RC after a few weeks. Is that OK?
>
> Couldn't you keep the old library in the archive for a while?
> Is a mass forced upgrade necessary? Beneficial?
Not beneficial but necessary since there is jackd which works only with
exactly one libjack and conflicts with all others. So having two libraries
installed would force users to remove jackd breaking all jack setups.
So I can't keep the old library. I could have just singled out those
packages that use the changed parts of the API but that would have broken
inter-distribution compatibility and would not have been consistent
either.
Robert.
--
Factorials were someone's attempt to make math LOOK exciting.
Attachment:
signature.asc
Description: Digital signature