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

Re: Package Reorganisations (here tetex-lib)



On Fri, Feb 16, 2001 at 01:47:42PM +0100, Christoph Martin wrote:
> After the removal of tetex-lib and tetex-dev from unstable, tetex-bin
> does still not move into testing:
> tetex-bin 1.0.7+20000807-7 (currently 1.0.6-7) (standard) (high) 
>          Maintainer: teTeX maintainers <debian-tetex-maint@lists.debian.org> 
>          tetex-bin uploaded 62 days ago, out of date by 60 days! 
>          valid candidate (will be installed unless it's dependent upon other buggy pkgs) 

From update_output.txt:
    tetex-bin: alpha: cjk-latex dvilx dvisvga libkpathsea-perl tfm-twmoe-kai 
                      tfm-twmoe-sung xdvik-ja

This indicates that when the tetex-bin source stuff was updated, it made
the above alpha packages uninstallable (possibly amongst others on the
other architectures).

All of these depend on tetex-lib, which disappears when tetex-bin is
upgraded.

> and I can't see why. I can't see any buggy package on which it depends
> and which are not in testing yet. I also do not understand why a
> package which is in testing and still depends on tetex-lib should hold
> tetex-bin to move into testing.

It does this because those packages will get broken if tetex-bin is
updated on its own; and the point of testing is that none of the packages
in it should be broken at any time.

The only way to ensure nothing's broken is to update all these at once,
and it's fine to update cjk-latex, but dvilx/dvisvga, libkpathsea-perl and
xdvik-ja are either not properly rebuilt or buggy.

The other problem is that testing's still far enough behind unstable
(and unstable's still broken enough [0]) that the testing scripts aren't
able to work out what things to try specially themselves.

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.

> 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) 

On alpha, the updated openssl breaks:

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
lynx-ssl likewise, but with arm and m68k
ssh-askpass-gnome, m68k and sparc (and the updated openssh/ssh has 10 RC bugs 
  anyway)
ssltelnet, telnet-ssl and telnetd-ssl has an RC bug, and isn't up to date
  on alpha, arm, m68k or sparc

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.

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

Cheers,
aj

[0] The new perl stuff breaks a fair few packages on non-i386 since it's
    not finished being ported yet, and that libstdc++2.10 is no longer
    available (it's replaced by libstdc++2.10-glibc2.2, which is binary
    incompatible aiui) manages to make apt uninstallable, and thus
    debconf, all the KDE stuff is waiting on the new qt-x11 package
    which doesn't build everywhere the old qt stuff did, and so on...

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
                      -- John S. Novak, III (The Humblest Man on the Net)

Attachment: pgppkocEdZXay.pgp
Description: PGP signature


Reply to: