Re: upgrade nightmare from slink to potato

cause I ran out of disk space in mid-upgrade (aaargh!). My original opinion about apt segfaulting was "bad luck", but after reading your mail I'm not so sure any more. However, I was impressed by dpkg's abilities to get all that mess repaired with a little help from the user.

Re: linking binfmt_misc with mime-types

On Wed, 6 Oct 1999, Brian May wrote: > >> What I really would like is a filesystem that can store a mime-type for > >> every file... That way no magic databases are required. In addition, the > >> kernel could be configured to assign default mime-types for different > >> file extensions, or somet

Re: linking binfmt_misc with mime-types

On Tue, 5 Oct 1999, Brian May wrote: [...] > > What I really would like is a filesystem that can store a mime-type for > every file... That way no magic databases are required. In addition, the > kernel could be configured to assign default mime-types for different > file extensions, or somethin

Re: dpkg -l format

On Tue, 5 Oct 1999, Colin Walters wrote: > > The output format of dpkg -l is terrible. Many package names exceed > the measly 16 characters allotted. Many, many times when trying to Yes. > what I really want to do is dpkg -l '*netscape*' | xargs dpkg --purge. I recommend dpkg --get-selectio

Re: Packages should not Conflict on the basis of duplicate functionality

On Wed, 29 Sep 1999, Clint Adams wrote: > > debian's attitude is: if you want something different, DIY. and more > > importantly, it lets you DIY. > > Err.. what Unix DOESN'T let you DIY? Every Unix lets you DIY, of course. The problem is the *'/(&% configuration done by most all distributions

Re: mtools

On Tue, 28 Sep 1999, David Weinehall wrote: > On Tue, 28 Sep 1999, Dale Scheetz wrote: > > [snip] > > > Guys, guys, guys... This is a discussion that was had quite a while ago, > > and which lead to the creation of xlib6. The whole point was that it was > > unnecessary glut to include a consol

Re: Packages should not Conflict on the basis of duplicate funct

On Tue, 28 Sep 1999, Clint Adams wrote: > > Ok, let's bring this back to implementation. How would you propose we > > handle > > this? Currently daemons install, set themselves up, and begin running. > > > > a) we can prompt. > > b) we leave everything off and let the admin turn it on (not an

Re: Censoring :) (was: Re: anarchism_7.7-1.deb)

On Tue, 28 Sep 1999, Jaldhar H. Vyas wrote: > > Why even involve debhelper? At least in the case of the Project Gutenberg > files some of which I have, they are just long ascii files so the rules > file could just stick them into (for example) /usr/share/doc/etexts call > doc-base and be done w

Re: problems with the perl5 packages

On Fri, 24 Sep 1999, Josip Rodin wrote: > On Fri, Sep 24, 1999 at 01:32:29PM +, Dale Scheetz wrote: > > So, why are there packages with depends lines that include both perl5 and > > a particular version, like perl-5.005? > > When a package depends on a virtual package which is provided by mu

Re: anarchism_7.7-1.deb

On Thu, 23 Sep 1999, Peter S Galbraith wrote: > I agree with you, and wish we'd toss all non-relevant packages > out, or at least move them into the data section. > (That said, I think stuff like coastline data that we could use > to make maps would be okay for the data section; Where do I draw >

Re: anarchism_7.7-1.deb

On Thu, 23 Sep 1999, Tomasz Wegrzanowski wrote: > I suggest renaming anarchist_7.7-1.deb to > anarcho-communism_7.7-1.deb or throwing it out of distribution > cause it have nothing to do with real anarchy > and make mess in peoples' minds > someone who doesnt really know what anarchy is after rea

grep-ing available made easy

Hello, I have just finished the first 90% (that is, I have a decently working beta version, but some things are still suboptimal) of something that could be vaguely described as Package: debcrawler Section: admin Priority: optional Version: 0.19 Depends: boa | httpd, lynx | www-browser, dpkg (>=

Re: A few changes

On Sat, 18 Sep 1999, Darren Benham wrote: > Bugs are no longer deleted!!! We don't have a way for you to access them > directly but there's an "official" location in the database where they're > being archived. We're trying to decide how to serve them up... by > requesting a bug number, obviousl

Re: Too many kernels in unstable

On Fri, 17 Sep 1999, Brian Mays wrote: > Perhaps we should keep the last two versions of each branch? In this > case, 2.0.35, 2.0.36, 2.2.10, and 2.2.12 (which is in Incoming). I > don't know. Let's see whether anyone objects to just keeping two > versions around. That seems reasonable. O