On Tue, Apr 11, 2000 at 09:45:11PM +0200, Eric Delaunay wrote: > > I'm running mostly up-to-date potato. If you could send me your patches so > > far, I could split it. If not that, then just tell me what needs to be done > > (which utilities to move to another package) and I'll try to do it. > > I've wrote preliminary support for scsidev at boot time but 1/ it needs > more test and 2/ it requires freeramdisk to be available in /bin or /sbin > (I filed a bug against util-linux to request for its inclusion). > Therefore the scripts are not yet ready for distribution. > > I also built a 0.6-1 release of hwtools without scsi support but I can > just upload full sources because it only builds on i386 and I cannot > compile it atm because my PC is still running slink. Perhaps I can better > send you the package and let you compile and upload it?
Feel free. > Anyway I guess I can upload my first release of scsitools package without > boot time support for scsidev. It works at least on my sparc. It will > conflict with hwtools << 0.6 but I don't know whether it should also > replaces hwtools? "Conflicts: hwtools (<< 0.6)" is all it takes, no Replaces. Note that the new hwtools should have a Recommends: on scsitools because existing users of scsi* stuff will lack the functionality... a debconf note should be added, too. > Another point is: what to do with closing bugs? I upgraded scsidev to > 2.10 in scsitools so it should fix 4 bug reports (#46622, #47340, #48306, > #30554). However is it right to include a Closes: line in the changelog of > scsitools? They're closing bugs of another package! Or should I reassign > the bugs to scsitools (hmm, not yet registered in Debian) or even close > them by hand? Just include the closes: line in the changelog, that's acceptable. dinstall won't recognize you as the maintainer (that's correct, actually), and will just mark the bugs as `fixed'. Then you should close the manually. -- Digital Electronic Being Intended for Assassination and Nullification
