|
Home > Archive > Debian Developers > July 2004 > DO NOT REMOVE the lib packages after updates
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
DO NOT REMOVE the lib packages after updates
|
|
| Eduard Bloch 2004-07-12, 5:58 pm |
| Package: libgtkhtml3.1-11
Severity: grave
This bug should be reassigned to a BTS entry for the maintainer (if we
had a such system).
The problem: the libgtkhtml3.x-y packages are always removed when a new
version is beeing uploaded. This behaviour is totaly stupid, it breaks
every package depending on the particular (SONAMEd) library package. For
example, this hits gtk-sharp the second time and now we have to make an
upload for no reason just to fix the dependency.
So now, Takuo, please listen and speak after me: WE DO NOT REMOVE
PACKAGES WHEN OTHERS DEPEND ON THEM. There is simply no reason, the
archive works fine if there are two versions of libgtkhtml-dev, just the
newer one is used. You do NOT need to remove them. If you feel that it
is neccessary, do at least contact the users of your package
(grep-available -F Depends libgtkhtml | grep Maintainer | sort -u) and
tell them about what you are going to do.
Regards,
Eduard.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.4.26-1-686
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8
--
Hauptsache es geht vorwärts - die Richtung ist egal.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Josselin Mouette 2004-07-12, 5:58 pm |
| On lun, 2004-07-12 at 17:12 +0200, Eduard Bloch wrote:
> The problem: the libgtkhtml3.x-y packages are always removed when a new
> version is beeing uploaded. This behaviour is totaly stupid, it breaks
> every package depending on the particular (SONAMEd) library package. For
> example, this hits gtk-sharp the second time and now we have to make an
> upload for no reason just to fix the dependency.
Of course they are always removed: they all come from the same source
package. And sometimes, the soname of a library changes, which means you
have to rebuild all packages using it. This is the case for many
libraries with an unstable ABI in Debian.
> So now, Takuo, please listen and speak after me: WE DO NOT REMOVE
> PACKAGES WHEN OTHERS DEPEND ON THEM. There is simply no reason, the
> archive works fine if there are two versions of libgtkhtml-dev, just the
> newer one is used. You do NOT need to remove them. If you feel that it
> is neccessary, do at least contact the users of your package
> (grep-available -F Depends libgtkhtml | grep Maintainer | sort -u) and
> tell them about what you are going to do.
Are you asking to have a new source package at each SONAME change?
Except in some rare cases (e.g. libpng), that's a very bad idea.
--
.''`. Josselin Mouette /\./\
: :' : josselin.mouette@ens-lyon.org
`. `' joss@debian.org
`- Debian GNU/Linux -- The power of freedom
| |
| Eduard Bloch 2004-07-12, 5:58 pm |
| #include <hallo.h>
* Josselin Mouette [Mon, Jul 12 2004, 06:16:01PM]:
> On lun, 2004-07-12 at 17:12 +0200, Eduard Bloch wrote:
>
> Of course they are always removed: they all come from the same source
Okay; Takou, please take my appologies for suspecting you in deliberate
removal of the source package (I was fooled by reportbug, #259001).
However, there is still no excuse for the removal of the binary package
by renaming it.
> package. And sometimes, the soname of a library changes, which means you
> have to rebuild all packages using it. This is the case for many
> libraries with an unstable ABI in Debian.
I know all these issues, I have maintained library packages in the past.
>
> Are you asking to have a new source package at each SONAME change?
Exactly.
> Except in some rare cases (e.g. libpng), that's a very bad idea.
And why? I just showed that it works.
Regards,
Eduard.
--
Ist feucht die Hose im August, dann hättest du auf's Klo gemußt.
| |
| Josselin Mouette 2004-07-12, 5:58 pm |
| On lun, 2004-07-12 at 18:31 +0200, Eduard Bloch wrote:
>
> And why? I just showed that it works.
And that it bloats the archive, is a pain to maintain, not speaking of
the security updates.
--
.''`. Josselin Mouette /\./\
: :' : josselin.mouette@ens-lyon.org
`. `' joss@debian.org
`- Debian GNU/Linux -- The power of freedom
| |
| Andreas Barth 2004-07-12, 5:58 pm |
| * Josselin Mouette (joss@debian.org) [040712 18:25]:
> On lun, 2004-07-12 at 17:12 +0200, Eduard Bloch wrote:
[vbcol=seagreen]
> Are you asking to have a new source package at each SONAME change?
> Except in some rare cases (e.g. libpng), that's a very bad idea.
A new source package is not required. You can just provide more binary
packages for a transition time from one source package.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Eduard Bloch 2004-07-12, 5:58 pm |
| #include <hallo.h>
* Josselin Mouette [Mon, Jul 12 2004, 06:35:58PM]:
> On lun, 2004-07-12 at 18:31 +0200, Eduard Bloch wrote:
>
> And that it bloats the archive, is a pain to maintain, not speaking of
> the security updates.
But it ensures a smooth transition without creating RC bugs in dozens of
other packages. It is not only disk space that matters.
Regards,
Eduard.
--
Die Leute, die den Reim für das wichtigste in der Poesie halten,
betrachten die Verse wie Ochsen-Käufer von hinten.
-- Georg Christoph Lichtenberg
| |
| Goswin von Brederlow 2004-07-12, 5:58 pm |
| Josselin Mouette <joss@debian.org> writes:
> On lun, 2004-07-12 at 18:31 +0200, Eduard Bloch wrote:
>
> And that it bloats the archive, is a pain to maintain, not speaking of
> the security updates.
> --
> .''`. Josselin Mouette /\./\
> : :' : josselin.mouette@ens-lyon.org
> `. `' joss@debian.org
> `- Debian GNU/Linux -- The power of freedom
It only bloats the archive during the transitional period. After all
packages depending on the lib have been recompiled the old package can
be removed.
The longer that period lasts the more important having 2 packages is
since otherwise you would have broken packages for the same amount of
time.
Having two packages also means the new package can go into sarge
without needing all its reverse depends to go at the same time, or not?
As for security updates that's pretty easy. Remove the old lib. You
wouldn't loose anything compared to removing it directly but you keep
packages working as long as there is no security bug.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Langasek 2004-07-12, 5:58 pm |
| On Mon, Jul 12, 2004 at 08:17:24PM +0200, Goswin von Brederlow wrote:
> Josselin Mouette <joss@debian.org> writes:
[vbcol=seagreen]
> It only bloats the archive during the transitional period. After all
> packages depending on the lib have been recompiled the old package can
> be removed.
> The longer that period lasts the more important having 2 packages is
> since otherwise you would have broken packages for the same amount of
> time.
The counterargument is that, without the pressure of RC bugs, the
transitional period will last longer. I think we would need to be able to
file "please recompile" bugs at RC severity to avoid compromising our
ability to get the libs section in shape for a release.
> As for security updates that's pretty easy. Remove the old lib. You
> wouldn't loose anything compared to removing it directly but you keep
> packages working as long as there is no security bug.
This does nobody any good once we have a stable release that includes the
parallel package for the old library.
And even "just remove the library" means piling more responsibility on our
straining security infrastructure that doesn't need to be there.
--
Steve Langasek
postmodern programmer
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Stephen Frost 2004-07-12, 5:58 pm |
| * Steve Langasek (vorlon@debian.org) wrote:
> On Mon, Jul 12, 2004 at 08:17:24PM +0200, Goswin von Brederlow wrote:
>
> The counterargument is that, without the pressure of RC bugs, the
> transitional period will last longer. I think we would need to be able to
> file "please recompile" bugs at RC severity to avoid compromising our
> ability to get the libs section in shape for a release.
I agree w/ Steve on this. You real problem is upstream changing the
SONAME very often. Educate them on why this is bad behaviour and try to
encourage them to have a stable library ABI for a while and to queue up
changes to reduce the overhead on the rest of the system. An
alternative, which takes alot more effort but works (better, imv), would
be to use versioned symbols.
>
> This does nobody any good once we have a stable release that includes the
> parallel package for the old library.
>
> And even "just remove the library" means piling more responsibility on our
> straining security infrastructure that doesn't need to be there.
Agree, this just doesn't work in reality.
Stephen
| |
| Stephen Frost 2004-07-12, 5:58 pm |
| * Andreas Barth (aba@not.so.argh.org) wrote:
> * Josselin Mouette (joss@debian.org) [040712 18:25]:
>
> A new source package is not required. You can just provide more binary
> packages for a transition time from one source package.
Without a new source package you'd be compiling two libraries from one
source w/ two different SONAME's. Getting that right, and forcing the
existing build system (whatever it is) to do it could be rather..
interesting.
Stephen
| |
| Goswin von Brederlow 2004-07-12, 8:49 pm |
| Steve Langasek <vorlon@debian.org> writes:
> On Mon, Jul 12, 2004 at 08:17:24PM +0200, Goswin von Brederlow wrote:
>
>
>
>
> The counterargument is that, without the pressure of RC bugs, the
> transitional period will last longer. I think we would need to be able to
> file "please recompile" bugs at RC severity to avoid compromising our
> ability to get the libs section in shape for a release.
There are two cases:
1. The source needs just recompiling without any change.
So why not just do it. Every DD can upload a binary-only recompile
NMU. Granted its work getting a package compiled on all archs but you
can do it. Or you can do a source NMU (after giving the maintainer
enough time) with just a new changelog entry so buildds comile it.
2. The source needs porting to the new lib.
This should only happen for API changes in which case there will be
lots of changes for the sources and the packages should probably
coexist for a longer time.
The old package should be marked for removal (but not yet removed) and
personally I would think RC bugs against its reverse depends are then
justified. Reason: 'Depends/Build-Depends on package marked for
removal.' Kind of preemptive will be uninstallable/buildable
bugreports. I hope every maintainer prefers getting such a bug
preemptive (so he has time enough to fix it) instead of getting the
real thing.
>
> This does nobody any good once we have a stable release that includes the
> parallel package for the old library.
Transitions should better be completed before a release. If it gets
into stable its hardly a short term coexistance anymore. I fully agree
that you should remove old transitional packages from testing before
release along with all its reverse depends. Besides it being a bad idea
you also get the problem of providing source for the old and new package.
I also wouldn't like to see sudden soname changes right before a
release without good reason. Too many new bugs (usually).
> And even "just remove the library" means piling more responsibility on our
> straining security infrastructure that doesn't need to be there.
I agree with you that it shouldn't enter stable and then the security
team is left unburdened.
> --
> Steve Langasek
> postmodern programmer
MfG
Goswin
PS: The last big lib changes rush (gnome 2.6) at first didn't keep old
libs and caused the new sources to be actually unbuildable. Some libs
had to be reuploaded with old and new versions to get the the rest
compiled at all. Think about that.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2004-07-12, 8:49 pm |
| Stephen Frost <sfrost@snowman.net> writes:
> * Andreas Barth (aba@not.so.argh.org) wrote:
>
> Without a new source package you'd be compiling two libraries from one
> source w/ two different SONAME's. Getting that right, and forcing the
> existing build system (whatever it is) to do it could be rather..
> interesting.
>
> Stephen
I hope I'm not mistaken here but when you include the soname in the
name of the library deb and it changes the DAK will keep the old
package in archive since there is no replacement for it, right?
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Colin Watson 2004-07-12, 8:49 pm |
| On Tue, Jul 13, 2004 at 03:26:50AM +0200, Goswin von Brederlow wrote:
> 1. The source needs just recompiling without any change.
> So why not just do it. Every DD can upload a binary-only recompile
> NMU.
Evil. That works on *one* architecture; if a change is required on all
architectures then it should not be a binNMU.
Replying merely for information,
--
Colin Watson [cjwatson@flatline.org.uk]
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2004-07-13, 2:50 am |
| Colin Watson <cjwatson@debian.org> writes:
> On Tue, Jul 13, 2004 at 03:26:50AM +0200, Goswin von Brederlow wrote:
>
> Evil. That works on *one* architecture; if a change is required on all
> architectures then it should not be a binNMU.
>
> Replying merely for information,
>
> --
> Colin Watson [cjwatson@flatline.org.uk]
As I said in the text following it. 
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Wouter Verhelst 2004-07-13, 2:50 am |
| On Tue, Jul 13, 2004 at 03:31:33AM +0200, Goswin von Brederlow wrote:
> I hope I'm not mistaken here but when you include the soname in the
> name of the library deb and it changes the DAK will keep the old
> package in archive since there is no replacement for it, right?
No; the DAK will remove the old package from the archive, because
packages are removed by source package.
--
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
-- with thanks to fortune
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2004-07-13, 7:53 am |
| Wouter Verhelst <wouter@grep.be> writes:
> On Tue, Jul 13, 2004 at 03:31:33AM +0200, Goswin von Brederlow wrote:
>
> No; the DAK will remove the old package from the archive, because
> packages are removed by source package.
Ok, so that only works if the source package name changes. 
God, api/abi changes suck. Why can't people just do it right and only
extend abis?
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Matt Zimmerman 2004-07-14, 2:48 am |
| On Mon, Jul 12, 2004 at 06:31:50PM +0200, Eduard Bloch wrote:
> #include <hallo.h>
> * Josselin Mouette [Mon, Jul 12 2004, 06:16:01PM]:
>
> Exactly.
It's not sane to do this.
>
> And why? I just showed that it works.
The fact that it is possible does not imply that it is a good idea.
--
- mdz
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Matt Zimmerman 2004-07-14, 2:48 am |
| On Mon, Jul 12, 2004 at 08:17:24PM +0200, Goswin von Brederlow wrote:
> As for security updates that's pretty easy. Remove the old lib. You
> wouldn't loose anything compared to removing it directly but you keep
> packages working as long as there is no security bug.
Preposterous. You're suggesting that we release Debian, and then when there
is a bug, "solve" it by removing the affected package from the archive.
The basis for your argument was that keeping the old library would make it
easier for the packages which depend on them, and you would have just made
those packages uninstallable by removing it.
--
- mdz
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Eduard Bloch 2004-07-14, 5:56 pm |
| #include <hallo.h>
* Matt Zimmerman [Tue, Jul 13 2004, 11:13:15PM]:
>
> It's not sane to do this.
So it is sane to XXXXup a dozen of dependent packages that rely on your
library? Without warnings? I think every library package maintainer should
realize that it is not only his lib package and maybe the few client
packages that he is responsible for - he shares the responsibility for
the state of all packages directly depending on this library.
Regards,
Eduard.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Matt Zimmerman 2004-07-14, 5:56 pm |
| On Wed, Jul 14, 2004 at 05:12:27PM +0200, Eduard Bloch wrote:
> #include <hallo.h>
> * Matt Zimmerman [Tue, Jul 13 2004, 11:13:15PM]:
>
>
> So it is sane to XXXXup a dozen of dependent packages that rely on your
> library? Without warnings? I think every library package maintainer should
> realize that it is not only his lib package and maybe the few client
> packages that he is responsible for - he shares the responsibility for the
> state of all packages directly depending on this library.
This is unstable we are talking about. That's where packages may be broken
in order to accomplish a goal.
Yes, it seems much more sane to me to simply remove the package and force a
transition, than to add complexity by trying to make the old and new
binaries available simultaneously in unstable.
--
- mdz
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Mark Brown 2004-07-15, 5:56 pm |
| On Wed, Jul 14, 2004 at 05:12:27PM +0200, Eduard Bloch wrote:
> So it is sane to XXXXup a dozen of dependent packages that rely on your
> library? Without warnings? I think every library package maintainer should
> realize that it is not only his lib package and maybe the few client
> packages that he is responsible for - he shares the responsibility for
> the state of all packages directly depending on this library.
It requires a bit of coordination with the other maintainers if you want
the change to go 100% smoothly. When I've done this in the past I've
contacted the maintainers of other affected packages, giving them access
to a prerelease version of the new package and we've worked out some
scheme for getting the transition done with the minumum of fuss. This
has always been a pretty painless process for me.
Obviously, just suddenly uploading the package without warning can cause
issues but they can be avoided without having to keep the old source
package kicking around.
--
"You grabbed my hand and we fell into it, like a daydream - or a fever."
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2004-07-16, 2:50 am |
| Matt Zimmerman <mdz@debian.org> writes:
> On Mon, Jul 12, 2004 at 08:17:24PM +0200, Goswin von Brederlow wrote:
>
>
> Preposterous. You're suggesting that we release Debian, and then when there
> is a bug, "solve" it by removing the affected package from the archive.
No, that was never ment for a release. Just unstable/testing for a
transitional period.
> The basis for your argument was that keeping the old library would make it
> easier for the packages which depend on them, and you would have just made
> those packages uninstallable by removing it.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2004-07-16, 2:50 am |
| Matt Zimmerman <mdz@debian.org> writes:
> On Wed, Jul 14, 2004 at 05:12:27PM +0200, Eduard Bloch wrote:
>
>
> This is unstable we are talking about. That's where packages may be broken
> in order to accomplish a goal.
>
> Yes, it seems much more sane to me to simply remove the package and force a
> transition, than to add complexity by trying to make the old and new
> binaries available simultaneously in unstable.
Would you advocate uploading libraries with new soname to experimental
and getting all reverse depends build against it (also in
experimental) so that a transition can then be pushed through within
days?
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Hamish Moffatt 2004-07-16, 2:50 am |
| On Wed, Jul 14, 2004 at 06:04:44PM +0100, Mark Brown wrote:
> It requires a bit of coordination with the other maintainers if you want
> the change to go 100% smoothly. When I've done this in the past I've
> contacted the maintainers of other affected packages, giving them access
> to a prerelease version of the new package and we've worked out some
> scheme for getting the transition done with the minumum of fuss. This
> has always been a pretty painless process for me.
>
> Obviously, just suddenly uploading the package without warning can cause
> issues but they can be avoided without having to keep the old source
> package kicking around.
Anything would be preferable to suddenly getting bug reports from your
users saying that your package just became uninstallable. I've been
caught out many times by the changing imagemagick library packages ;-(
I think the library churn also leaves us in a bad position wrt
commercial software on Debian. In particular I have some experience with
hardware design tools. Often these are aimed at old Red Hat versions
(even brand new builds can be aimed at RH 7.x or 8.x), and they use
libstdc++ versions which existed at one time in Debian but actually
only *in between* stable releases, so they are really hard to get now.
I guess the LSB should address that.
Hamish
--
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Matt Zimmerman 2004-07-16, 2:50 am |
| On Fri, Jul 16, 2004 at 06:12:35AM +0200, Goswin von Brederlow wrote:
> Would you advocate uploading libraries with new soname to experimental
> and getting all reverse depends build against it (also in
> experimental) so that a transition can then be pushed through within
> days?
I'm not sure. What is the advantage over doing the same thing with
s/unstable/testing/ and s/experimental/unstable/ ?
--
- mdz
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2004-07-16, 2:50 am |
| Matt Zimmerman <mdz@debian.org> writes:
> On Fri, Jul 16, 2004 at 06:12:35AM +0200, Goswin von Brederlow wrote:
>
>
> I'm not sure. What is the advantage over doing the same thing with
> s/unstable/testing/ and s/experimental/unstable/ ?
Breaking unstable for possibly weaks and preventing any new packages
(that depend on the lib) from entering sarge.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Matt Zimmerman 2004-07-16, 5:54 pm |
| On Fri, Jul 16, 2004 at 09:45:56AM +0200, Goswin von Brederlow wrote:
> Matt Zimmerman <mdz@debian.org> writes:
>
>
> Breaking unstable for possibly weaks and preventing any new packages
> (that depend on the lib) from entering sarge.
These sorts of problems are trivial to fix; if the maintainer leaves his
package broken for a week or more, and its breakage is interfering with the
release, then it should be an NMU candidate.
--
- mdz
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2004-07-16, 5:54 pm |
| Matt Zimmerman <mdz@debian.org> writes:
> On Fri, Jul 16, 2004 at 09:45:56AM +0200, Goswin von Brederlow wrote:
>
>
> These sorts of problems are trivial to fix; if the maintainer leaves his
> package broken for a week or more, and its breakage is interfering with the
> release, then it should be an NMU candidate.
>
> --
> - mdz
For API changes fixing it might not be easy. For pure ABI changes you
are right.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Hamish Moffatt 2004-07-18, 7:51 am |
| On Fri, Jul 16, 2004 at 09:54:55AM -0700, Matt Zimmerman wrote:
> On Fri, Jul 16, 2004 at 09:45:56AM +0200, Goswin von Brederlow wrote:
>
> These sorts of problems are trivial to fix; if the maintainer leaves his
> package broken for a week or more, and its breakage is interfering with the
> release, then it should be an NMU candidate.
It's only trivial if the changes are only to the ABI. If they're API
changes, it may be anywhere from trivial to extremely difficult.
Hamish
--
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|