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

Re: Package Reorganisations (here tetex-lib)

Anthony Towns writes:
 > In this case, giving the scripts a hint to try a bit harder with tetex-bin
 > ends up fixing enough other packages that the couple above that break
 > is a worthwhile loss. So tetex-bin will go in with the next archive run in
 > a few hours.

Thx. tetex-bin is in now.

 > > We have a similar situation with openssl:
 > > 
 > > openssl 0.9.6-1 (currently 0.9.4-5) (optional) (low) 
 > >          Maintainer: Christoph Martin <christoph.martin@uni-mainz.de> 
 > >          openssl uploaded 35 days ago, out of date by 25 days! 
 > >          valid candidate (will be installed unless it's dependent upon other buggy pkgs) 
 > openssl: alpha: apache-ssl libapache-mod-ssl libnet-ssleay-perl lynx-ssl 
 >                 ssh-askpass-gnome ssh-askpass-ptk ssltelnet sslwrap stone-ssl
 >                 stunnel telnet-ssl telnetd-ssl w3m-ssl
 > apache-ssl has been updated, but not recompiled on arm, m68k and sparc
 > libnet-ssleay-perl has been updated, but not recompiled on m68k or sparc

libnet-ssleay-perl does not build from source. There is a serious
bugreport pending.

 > lynx-ssl likewise, but with arm and m68k
 > ssh-askpass-gnome, m68k and sparc (and the updated openssh/ssh has 10 RC bugs 
 >   anyway)

The version of ssh in testing is the same as in stable and depends on
libssl09(4) . So we will not have openssl 0.9.6 until these bugs are
resolved? This is bad.

 > ssltelnet, telnet-ssl and telnetd-ssl has an RC bug, and isn't up to date
 >   on alpha, arm, m68k or sparc

only sparc has an official build machine where one can compile his
There is still no list of build machines for all architectures. So I
can not try to build the packages by hand to speed the process up.

 > The updated packages may well have been built with openssl 0.9.4 too,
 > I didn't check. That's obviously no good, if so.

stone-ssl, stunnel and w3m-ssl are all linked against libssl09(4,5). I
have filed bugreports against them.

 > Having separate openssl094 (in oldlibs) and openssl096 source packages
 > would probably be more ideal here, as far as transitioning goes.

Would that really help? That would mean having libssl094 (providing
libssl09) and libssl095 (because some packages are linked against
that) in oldlibs.


Reply to: