Re: Upcoming Debian Releases
On Sat, 11 Jan 1997, Chris Fearnley wrote:
> Another class of critical bug is a packaging bug.
Packaging bugs can be either critical or not, and can cause system bugs,
or not. Just because it is a packaging bug doesn't make it critical. It
does, though, typicaly make them easy to fix, so with an adequate testing
schedule these should never be a problem by release time.
> For example, if
> package foo pre-depends on non-essential package bar, then choosing foo
> in dselect will (almost certainly) cause the entire installation to
> fail.
No unless package foo is esential. Otherwise dselect will only fail on the
installation of the one package foo.
> Hence package foo's bug affects something very important.
Only if foo is an integral part of the system.
There
> are other potentially critical bugs in any package's control info or
> maintainer scripts that if they affect the system, should be considered
> critical (even if the binary itself is innocuous).
They can be critical whether they effect the system or not. They are
either critical system bugs, or critical package bugs.
The reason I made a distinct class for system, seperate from package was
to make it clear that these class distinctions were not part of the issue
of critical vs non-critical bugs.
There are non-critical system bugs, just like there are non-critical
package bugs. For instance, the non-existance of a hostname file in /etc
after an upgrade/install, is not anywhere near as critical as a bug in the
init script that causes the system to fail to boot.
[Obviously, most
> packaging bugs are minor and should not be considered critical.]
That's not clear without specifics. Each bug needs to be evaluated, based
on what it breaks and how important it is to have it fixed. I would always
rate system critical bugs over ones that are only package critical, and
both classes above non-critical bugs of all types.
> Since it is possible to have critical packaging bugs, I think every
> package released after the code freeze should be carefully inspected
> for bugs of this nature.
If the individual package maintainers (and I know I am deficient in this
reguard as well) would verify by installation that the dependencies work
properly (on a bare system if that is possible). I know from personal
experience just how hard this can be to impliment, but it is of
non-trivial importance that at least packages uploaded to master should
install.
> Debian 1.1 had the cflow bug; Debian 1.2 has
> a bunch of X dependency bugs (these are less serious then that cflow
> bug which was a show-stopper). So I'm not speaking theoretically!
>
Both of these issues speak to the need to get started down the right
channels early in the development cycle, so there is time at the end of
the cycle to do some proper testing AND have time to fix anything that is
found flawed.
As a package maintainer I appreciate just how hard it is to contribute to
the testing effort. Maybe we should enlist some of our more savy users,
with adequated resources as beta test sites who will take a "very" early
release and just test how it installs.
Many of our difficulties only show up when a particular system or hardware
configuration is installed. Folks who don't use apache or any other
package of that sort aren't likely to find bugs even if they install the
package, and the same goes for other "specialized" sections of the
distribution, but at least the installation portion would be handled.
Many of the problems that are being reported agianst dselect are the
result of poorly coordinated package dependency and not truely the fault
of dselect.
We need to focus on making packages that will install properly within the
framework of the packaging software, rather than finding more and more
exotic ways to use/miss-use the dependency feature.
One of the ways to deal with recovering from mistakes in dependencies,
would be to have the capability of editing the the .deb file to modify
those declarations. Then the archive maintainer, or a CD manufacturer, or
a mirror archive, could fix such problems at the site instead of needing
to wait for the next release of that package and it's percolation up
through the mirrors.
Back to the testing issue: it is easy to get folks interested in
maintaining packages and hard to get them interested in a system wide
testing scheme, for fairly obvious reasons. Folks with the resources might
consider focusing their efforts in these areas.
Later,
Dwarf
------------ --------------
aka Dale Scheetz Phone: 1 (904) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: dwarf@polaris.net Tallahassee, FL 32308
------------ If you don't see what you want, just ask --------------
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: