Re: recommended way to fix Bug#492814 ?
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
Reply to: