Bug#354674: What on earth?
On Thu, Apr 13, 2006 at 08:25:55PM -0400, Adam C Powell IV wrote: > On Thu, 2006-04-13 at 19:58 -0400, David Nusinow wrote: > > On Thu, Apr 13, 2006 at 07:09:55PM -0400, Adam C Powell IV wrote: > > > *Think* for a moment about the consequences. This is not a simple > > > rebuild, this is a serious problem. > > I agree and I take full responsibility for the issue. I'm sorry for the > > trouble. I'm fully willing to put back the .la files on request from the > > release team, who I should definitely have coordinated with beforehand. > > Note that I would have done so if I'd realized the magnitude of the > > problem, and not doing so was entirely my error. > Wow. Thank you. This would help in the short term, though I suspect > the damage is done and the other packages are "fixing" their "bugs" at > this point. I agree that the release team should decide. You won't get any argument from the release team about whether it's ok for .la files to be dropped from packages, in cases where the library also integrates with pkg-config. In addition to pkg-config being much easier to integrate with plain Makefiles, its dependency handling is much better able to cope with changes to library relationships. It's just the timing that becomes an issue. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#354674: What on earth?
On Thu, Apr 13, 2006 at 07:58:05PM -0400, David Nusinow wrote: > On Thu, Apr 13, 2006 at 07:09:55PM -0400, Adam C Powell IV wrote: > > *Think* for a moment about the consequences. This is not a simple > > rebuild, this is a serious problem. > > I agree and I take full responsibility for the issue. I'm sorry for the > trouble. I'm fully willing to put back the .la files on request from the > release team, who I should definitely have coordinated with beforehand. > Note that I would have done so if I'd realized the magnitude of the > problem, and not doing so was entirely my error. And this deserves applause. Recognizing errors, or lack of comunnication due to one, and showing a positive attitude is something that has to be more spread on this project. David, Daniel and other X team guys, my thanks for your great work, effort and positive attitude. -- Jose Carlos Garcia Sogo [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#354674: What on earth?
On Thu, 2006-04-13 at 19:58 -0400, David Nusinow wrote: > On Thu, Apr 13, 2006 at 07:09:55PM -0400, Adam C Powell IV wrote: > > *Think* for a moment about the consequences. This is not a simple > > rebuild, this is a serious problem. > > I agree and I take full responsibility for the issue. I'm sorry for the > trouble. I'm fully willing to put back the .la files on request from the > release team, who I should definitely have coordinated with beforehand. > Note that I would have done so if I'd realized the magnitude of the > problem, and not doing so was entirely my error. Wow. Thank you. This would help in the short term, though I suspect the damage is done and the other packages are "fixing" their "bugs" at this point. I agree that the release team should decide. I hope such problems can be avoided in the future. Cheers, -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]
Bug#354674: What on earth?
On Thu, Apr 13, 2006 at 07:09:55PM -0400, Adam C Powell IV wrote: > *Think* for a moment about the consequences. This is not a simple > rebuild, this is a serious problem. I agree and I take full responsibility for the issue. I'm sorry for the trouble. I'm fully willing to put back the .la files on request from the release team, who I should definitely have coordinated with beforehand. Note that I would have done so if I'd realized the magnitude of the problem, and not doing so was entirely my error. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#354674: What on earth?
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]
Bug#354674: What on earth?
On Thu, Apr 13, 2006 at 09:48:40AM -0700, Steve Langasek wrote: > The problem is not rebuilding, the problem is having several dozen other > packages completely blindsided by this change *with no coordination*. The > Xorg 7.0 transition was presented to the release team as "no big deal, just > splitting the package". Instead, it's leaving half the packages in the > build queue unbuildable because of disruptive changes that no one thought > worth mentioning. This is entirely my own inexperience showing and I take full responsibility for it. I didn't realize that the monolithic to modular transition would affect much more than the Xorg packages themselves, and I tried to mitigate any problems that I saw beforehand. The packages sat in experimental for months and I dogfooded them as best I could with the resources available to me. > I agree with the principle of dropping .la files in cases where .pc files > are available as a better substitute, but not without *coordinating* with > people. The repeated statements from the release team that library changes > should be coordinated aren't some whim of those wacky RMs that should be > ignored; keeping a handle on the disruptive changes going into unstable is > essential if we're going to keep the announced release schedule. Again, I didn't realize this would be so disruptive. When we removed the .la files in the X packages previously it didn't seem to be a big deal to trigger the binNMU's so I didn't pay it much mind. I never thought to scale up the problem and this was my mistake in this particular case. > So far I'm very unimpressed with the resultant bug count from the Xorg 7 > transition. The blame rests entirely on me of course, and I'm going to continue working to fix the problems. Unfortunately, even after being incredibly conservative with this transition by waiting for the other major vendors to shake out significant bugs, and for the major packaging bugs to be worked out by Ubuntu, as well as significant amounts of time in experimental, I couldn't get the >100 packages all in perfect working order before uploading to unstable. I'm afraid there's only so much I could do, and for that I can only apologize and fix things now. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#354674: What on earth?
On Thu, Apr 13, 2006 at 07:12:48PM +0300, Daniel Stone wrote: > 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. The problem is not rebuilding, the problem is having several dozen other packages completely blindsided by this change *with no coordination*. The Xorg 7.0 transition was presented to the release team as "no big deal, just splitting the package". Instead, it's leaving half the packages in the build queue unbuildable because of disruptive changes that no one thought worth mentioning. I agree with the principle of dropping .la files in cases where .pc files are available as a better substitute, but not without *coordinating* with people. The repeated statements from the release team that library changes should be coordinated aren't some whim of those wacky RMs that should be ignored; keeping a handle on the disruptive changes going into unstable is essential if we're going to keep the announced release schedule. So far I'm very unimpressed with the resultant bug count from the Xorg 7 transition. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#354674: What on earth?
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'.
> * 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.
> * And which has not been discussed on debian-devel or any other
> Debian list as far as I can tell (Google search).
Yes.
> 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.
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.
signature.asc
Description: Digital signature
Bug#354674: What on earth?
On Thu, 2006-04-13 at 11:12 -0400, Adam C Powell IV wrote:
> Greetings,
>
> Please tell me if I have this right:
> * You don't like .la files
> * So you're unilaterally removing them from a core package
> (libxcursor) with dozens of reverse-depends, breaking all of
> them
> * Even though they're a years-old and very well established
> technology
> * Which upstream libtool has not yet decided to eliminate ("It's
> already under discussion")
> * And which has not been discussed on debian-devel or any other
> Debian list as far as I can tell (Google search).
Okay, my mistake, the removal of .la files throughout X packages
indicates that this was an X-wide decision, not an isolated developer.
But I still don't see any discussion on Debian lists outside of this one
bug.
"I guess that's why they call it unstable..."
Cheers,
-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]
Bug#354674: What on earth?
Greetings,
Please tell me if I have this right:
* You don't like .la files
* So you're unilaterally removing them from a core package
(libxcursor) with dozens of reverse-depends, breaking all of
them
* Even though they're a years-old and very well established
technology
* Which upstream libtool has not yet decided to eliminate ("It's
already under discussion")
* And which has not been discussed on debian-devel or any other
Debian list as far as I can tell (Google search).
Can you really be serious?
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?
-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]
