Federico Gimenez Nieto wrote: > Thanks, now it is bulding without problems, it is uploaded at > mentors
IMHO it is useless to make an upload to sid fixing the current RC bug now, because you'd need a sourceful upload for the transition anyway, and the GNUstep stack (including gnustep-dl2) is not releasable with the current combination of the core libraries. So the focus must be to prepare for the transition -- you can (and should) tag the bug pending to avoid duplicate efforts, but an upload to sid would be a waste. Your (and your sponsor's) call, of course. > > (The GSMethodList FTBFS is gnustep-base/1.20.x-specific so you can't > > notice it in sid, but it will become RC when the new Base is uploaded > > in unstable. It is fixed upstream, easily backportable, but > > unfortunately the change is ABI-breaking for EOControl :-(.) > > Is there any chance to prevent this FTBFS while keeping EOControl in > good shape? Possibly, for someone familiar with the code. However, I doubt upstream would be interested to assist here, because there were other ABI breaks since the last release (IOW: it is kinda pointless for them to try to avoid this ABI break for the sake of one distro when they've certainly introduced others.) What I suggest (to avoid introducing debian-specific soname and passing through NEW twice) is the following: 1. Discuss with upstream their plans for the new release -- when it is supposed to happen, which libraries will have the soname bumped (All for consistency? Only those with incompatible changes? Etc.) 2. Depending on 1), upload to experimental either a SVN trunk snapshot with the new upstream soname(s) (provided they'll keep the ABI stable until the actual release), or upload with a minimalistic fix for the FTBFS + debian-specific soname, again in experimental. Experimental, because it would allow you/us to control precisely the moment for the upload to sid (when the release team gives green light for the transition) -- NEW processing can be very slow or very fast, so it's best to avoid any uncertainty and eventual delays during the GNUstep transition. I call the second scenario "unfortunate", because you'd have to bump the soname *again* when you package next upstream release, whenever that happens. (In addition, something as important as a library interface version is best to coincide with upstream, in an ideal world even among different distros.) 3. Another variant, dirty and unprofessional in my opinion, is to keep the soname(s) the same regardless of the ABI-incompatible changes. This was done numerous times in the past for Objective-C libraries in Debian (including core libraries), almost always not deliberately and discovered post-factum. We'll survive, but it is a very dangerous path to follow. I advise you to avoid this at all costs. The fact that there are no reverse dependencies within the Debian archive is more or less irrelevant -- it means there won't be RC bugs to other packages because of the silent ABI break, but some users of the library will surely be unpleasantly surprised. Besides, I intend to fix steptalk (#583100) to build the GDL2 bundle so there will be at least one reverse dependency. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
