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

*--* 1998-05-19 laptop/apt bo->hamm upgrade report



CONFIGURATION
	machine:	IBM Thinkpad 486 (360CE)
	memory:		20MB
	disks:		1.44 floppy
			240MB HD
	cdrom:		n/a
	scsi:		n/a
	sound card:	not supported (?)
	video card:	WD90C24
	modem:		n/a
	net card:	Kingston EtheRX PCMCIA
	partitions:	/dev/hda1 (20MB swap)
			/dev/hda2 (~200MB root)

TESTING TARGET:
	task:		upgrade bo to hamm using apt
	source:		apt_0.0.13-bo1, mirrors as of 1998-05-18
	state:		laptop with rather minimal, 170MB bo setup, well
			configured

PREPARATION:
	Install apt.  Edit /etc/apt/sources.list and run 'apt update'
	to get new package list.

	Remove extraneous packages manually in preparation, simply to
	clear up disk space.

RESULT:
	Upgrade went very smoothly.  apt report 205 packages upgraded,
	37 newly installed, 14 to remove and 1 not upgraded.
	Bash/readline bug not tickled.  

PROBLEMS:
	apt 0.13 had a problem sometimes with a pkg being held (bug
	#22618).  Jason says that will be fixed in the next version.
	#This lead to my PCMCIA problems.

	util-linux not upgraded; this is because of getty, which is no
	longer in the archive.  Solution: 'apt-get install
	util-linux'.

	Random dpkg core dump during installation: Core was generated
	by `dpkg --unpack tetex-bin_0.9-4.deb tetex-base_0.9-5.deb
	elvis-tiny_1.4-5.deb tet...'.  Program terminated with signal
	11, Segmentation fault.  Don't even know where to start
	reporting that one.

	emacsen-common installation has some serious problems.  First,
	the lisp-compilation ran twice, once on emacsen-common
	installation, and once with the other packages were installed
	(bug to be submitted).  Second, dependancies in the lisp
	packages themselves is ignored at emacsen-common postinst
	time, leading to bad ordering of lisp package compilation (bug
	#21143).  Neither are critical as far as hamm release mgmt,
	#however.

	xdm was started up prematurely, I believe.  It cycled a number
	of times, not really able to start up, just flashing the
	screen, dying, trying again, ad infitium (looks the same as
	Bug#22685).  I was able to proceed installing packages in the
	interrum periods when the console was available (about a one
	second window), and eventually it stopped cycling (cf
	Bug#22544 et al).  Unfortunately, xdm started scrampling the
	console after cycling so many times, and capitalized
	characters got hosed for some reason (bug to be submitted).

	A number of packages are still installed that are libc5 based.
	This is probably more of a feature with our archive than
	anything else.  Here's the list:
	# pkg-deptree libc5
	libc5
	  bitchx-bin
	  cfgtool
	  ibcs
	  ksmbfs
	  libdb1
	  libg++27
	    apt
	  libgdbm1
	  libjpeg6a
	  libpam0
	    libpam0-altutil
	      libpam0
	  libpam0-altutil
	  libpaper
	  libpng1
	  libpwdb0
	    libpam0-altutil
	  libreadline2
	  libtiff3
	  ncurses3.0
	    bitchx-bin
	    libreadline2
	    pine
	  pcmcia-cs
	    pcmcia-modules-netboot.3
	  pine
	  slang0.99.34
	  svgalib1
	    svgalib1-bin
	  svgalib1-bin
	  tcl74
	    expect
	  tcl75
	  tcl76
	    tk42
	  termcap-compat
	  tk42
	  wg15-locale
	  xaw3d
	  xlib6
	    tk42
	    xaw3d
	  xpm4.7
	  zlib1
	    libtiff3
	  apt

	Other problems may exist; testing still proceeding on the box.
	It's late and I want to get this out.
	
RECOMMENDATIONS:

	* 'apt dist-upgrade' is a robust and recommendable bo/hamm
	  upgrade.  One problem with users may be getting things in an
	  ok state to begin with.  Other may be problems for users
	  where required packages are not actually put on hold (i.e.,
	  PCMCIA).

	* apt should tell why packages are held back when the are held
	  back.

	* apt should detect and respond to low disk space limitations
	  in the download cache area (/var/cache/apt/archive). The
	  simplest solution would be for it to simply 'apt-get clean'
	  itself every now and again, when disk space is neeed.

	* X11 upgrade was not as smooth as it should be.  xdm should
	  not be started during xbase configure step, or else it
	  should only be started conditionally, given that we could
	  monitor that it was starting ok.  Probably easier not to
	  start it at all, but rather to instruct the user how to test
	  it and tell them to boot to get it going?
	
-- 
.....A. P. Harris...apharris@onShore.com...<URL:http://www.onShore.com/>


--
To UNSUBSCRIBE, email to deity-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: