On Thu, 2006-04-13 at 19:12 +0300, Daniel Stone wrote:
> On Thu, Apr 13, 2006 at 11:12:06AM -0400, Adam C Powell IV wrote:
> > Please tell me if I have this right:
> > * You don't like .la files
>
> Yes.
>
> > * So you're unilaterally removing them from a core package
> > (libxcursor) with dozens of reverse-depends, breaking all of
> > them
>
> Yes.
>
> > * Even though they're a years-old and very well established
> > technology
>
> .la files? I wouldn't call them 'very well established'.
Okay, then 'widespread', as is evident from the number of broken
packages.
> > * Which upstream libtool has not yet decided to eliminate ("It's
> > already under discussion")
>
> And X.Org upstream are currently seriously discussing whether or not to
> eliminate libtool, at which point you get broken away. This, believe it
> or not, a) improves portability, and b) makes you immune to further
> changes.
Okay, I misunderstood, s/libtool/Xorg/. Even so, what "further
changes"? There are no further changes yet, there are merely
discussions. This doesn't change that you acted unilaterally.
> > * And which has not been discussed on debian-devel or any other
> > Debian list as far as I can tell (Google search).
>
> Yes.
This is the main problem. In numerous other transitions, from udev/hal
to C++, we had fair warning and could coordinate release schedules. See
Steve's post.
> > Can you really be serious?
>
> Yes.
>
> > For example, if the maintainer of GLib decides (s)he doesn't like the
> > way it handles modules, and upstream *might* at some point change the
> > behavior, is that alone enough justification to change it and break all
> > of its dozens of reverse-depending packages?
>
> If the dependent packages can be fixed with a rebuild, and the reason is
> solid, rather than, 'I'm bored'? Yes.
So I'm supposed to rebuild all of the dependencies between my package
and libxcursor, like multiple GNOME and KDE libraries (GNOME in my
case), just to build my package? And then what? Upload it? I can't,
because those intermediate libs are broken in unstable, so it won't
autobuild.
And who's to say the interfaces won't change before the next upload of
those intermediates? For example, GNOME is in the middle of its
2.12-2.14 transition, with dozens of packages in flight from alioth via
experimental. It would *really* have helped if you had let them know of
these plans *before* they started uploading 2.14 packages.
Now everybody needs to wait while the maintainers of those packages
build and upload. In the correct order. Regardless of other release
plans. With no notice.
*Think* for a moment about the consequences. This is not a simple
rebuild, this is a serious problem.
> Is a rebuild really that phenomenally onerous for you? In the time
> spent arguing this point, tons of packages could've been simply rebuilt.
> I don't see where the problem lies, unless you happen to enjoy random
> flamebait more than actual productive work.
Flamebait? Well, if you consider discussions on stranding a large
fraction of Debian's 1000 part-time volunteer developers without the
ability to build their packages in unstable to be "random flamebait", I
really can't help you.
Regards,
-Adam
--
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
