On Tue, Jul 29, 2008 at 01:53:14PM -0700, Steve Langasek wrote: > On Tue, Jul 29, 2008 at 09:49:36AM -0700, Ivan Kohler wrote: > > On Mon, Jul 28, 2008 at 09:52:24PM -0700, Steve Langasek wrote: > > > On Mon, Jul 28, 2008 at 07:58:46PM -0700, Ivan Kohler wrote: > > > > * Revert to upstream 2.4.1 to get this compiled & working against lenny > > > libxcrypt (closes: Bug#487487). > > > > Why in the world, with that changelog entry, did the build-deps get > > > changed > > > to point to a sid-only version of libxcrypt in the first place? > > > They weren't. The build-deps were changed to point to they previous > > version of libxcrypt, which is in *lenny*. They were changed not "just > > because", but because the newer version isn't working, and there is > > little chance of getting it working soon. > > Ok; apparently I misread the control file. > > Build-Depends: [...] libxcrypt-dev (>= 2.4), libxcrypt-dev (< 3.0) > > Apparently, my question was meant to be: why was a package uploaded to > unstable that build-depends on a version of libxcrypt that's only in > testing (since libxcrypt-dev 3.0-2 was uploaded over a month before your > libpam-unix2 upload)?
Because that's the version it needs to be functional. libpam-unix2 2.4 needs libxcrypt before 3.0. It doesn't work with libxcrypt 3.0. > I'm not seeing how you expected this to work, so I'm > not sure what to recommend as a way out of this mess. I expected (wrongly, obviously) it would pick up the build dependency and build against the correct packages... > > > Also, why do you propose to address this by adding an epoch to a library > > > (which is never good), > > > Precisely why I asked for advice before doing anything... it did sound > > like there might be a better way.. > > > > instead of fixing the libxcrypt build problem in > > > unstable and getting that unblocked? > > > Perhaps I was unclear. > > > Take a look at the bug report, please. > > > To fix the libxcrypt build problem in unstable, I'll need to revert to > > the previous version. > > Why can't you *fix* the bug? It's a trivial build failure to fix - just > stop building with -Werror. > > > 3.0 currently in unstable is unsuitable for release. > > For reasons other than the build failure? Yes. libpam-unix2 needs the previous version to build and work correctly. > That is certainly not evident from the BTS. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=487487 > If the build failure is the only reason, I don't see why you > wouldn't just fix it. The libxcrypt build failure is not really relevant. It could have built fine and there would still be the same exact problem. > If there are other reasons, they should be documented > in the BTS. Yes, they are, as noted: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=487487 > > How do you suggest I revert to libxcrypt 2.4 to fix the build problems > > in unstable *without* using a library epoch? > > I don't. Okay, so you are confirming that the library epoch, distasteful though it may be, is still the best/correct way to fix the problem. I will prepare and upload corrected packages as per my original suggestion: - libxcrypt version 1:2.4-2 (no changes from 2.4-2 currently in testing) - libpam-unix2 1:2.4.1-2 version of libpam-unix2 (no changes except to update the build-dep) If there is any alternative procedure the release team or anyone else would like me to follow, please let me know! I'm here asking BEFORE I do anything, so please tell me now if I'm Doing It Wrong. Alternatively, if there is absolutely no way this is going to get into lenny *anyway*, let me know and I won't waste my time, I'll just request the packages be removed entirely. -- _ivan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
