[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: recommended way to fix Bug#492814 ?



On Tue, Jul 29, 2008 at 10:19:44PM -0700, Steve Langasek wrote:
> On Tue, Jul 29, 2008 at 02:29:18PM -0700, Ivan Kohler wrote:
> 
> > > > 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
> 
> There's nothing in bug #487487 that explains why libpam-unix2 can't use the
> newer version of libxcrypt.  I had to figure this out for myself by
> downloading the libpam-unix2 2.4.1 package, to see that it uses a function
> from libxcrypt1 that's no longer present in libxcrypt2.
> 
> > > 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.
> 
> Which problem?  The problems I can see are:
> 
> - libpam-unix2 2.5.0 was broken, because it was built against the old
>   version of libxcrypt which it's not compatible with

No!  It was just broken.  Wouldn't authenticate blowfish passwords.  See 
Bug #487487 above.

Being compiled against the old version of libxcrypt wasn't the problem 
as far as I could tell - it didn't work with the new one either.  Didn't 
even link the shared library (hence the "no blowfish support" symptom).

Just like you can't use libpam-unix 2.4 with libxcrypt2, you can't use 
libpam-unix2 2.5 with libxcrypt1.

libpam-unix2 2.4 needs libxcrypt 2.4
libpam-unix2 2.5 needs libxcrypt 3.0

The function name you point out was changed between libxcrypt 2.4 and 
3.0 such that you *can't* mix and match as you are suggesting.

> - libxcrypt is failing to build

This problem is irrelvant, as noted previously.

> - libpam-unix2 1:2.4.1-1 is failing to build because it has a versioned
>   build-dependency on a previous version of libxcrypt
> 
> From what I see, fixing libxcrypt so that it builds would have also
> addressed the first problem because libpam-unix2 2.5.0 could have been
> rebuilt against the new libxcrypt;

libpam-unix2 2.5 and the new libxcrypt were already tried.  They don't 
work at present, as previously noted.

> but now you've uploded an older version
> of libpam-unix2 which introduces a new incompatibility, so you would have to
> both fix libxcrypt, and upload libpam-unix 2.5.0 again.

*sigh* No, 2.5.0 is broken. 

> I still think that's the best option, unless there's some *other*
> undocumented reason why libxcrypt2 is unsuitable for release.
>
>  I think it's
> the best option because it avoids epoching a library, and because it would
> continue to use the libpam-unix2 2.5.0 package which, aside from not being
> able to do password changing at present, appears to have at least received
> some testing.

It avoid epoching a library, but also avoids actually working (since 
2.5.0 is broken), so I'm not seeing how that is a viable option.
 
> > > > 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)
> 
> The problem with this is that it brings in a "new" upstream version of
> libpam-unix2, 2.4.1, which has before now not been in unstable or testing.

libpam-unix2 1:2.4.1 has *already* been in unstable for a week.  It 
works fine other than the build problems, thankfully.

> That should not normally qualify for a freeze exception, AFAICS; I'll let
> someone else on the release team make the decision whether it should get
> that freeze exception, but I believe the alternate approach I outlined above
> allows for better QA by comparison.

Well, I'll get working packages uploaded first, then I'll worry about 
begging for the freeze exception.  Since libpam-unix2 has been with us 
for a few stable releases already, it seems a disservice to our users to 
drop it if there is any way we can help it.

Sorry if I was unclear about the new vs. old libpam-unix2 and libxcrypt.  
Hopefully now you understand the situation.  If not, by all means, let 
me know what is still unclear.

Since it looks like I'm not going to get any usable alternative 
suggestions or advice, I have prepared the new packages and will upload 
them shortly.  Please do tell me if I should be doing something 
different...

libxcrypt    1:2.4-1   (no changes from 2.4-2 currently in testing)

libpam-unix2 1:2.4.1-2 (no changes other than to update the build-dep 
                        on libxcrypt to fix #492814)

-- 
_ivan


Reply to: