Culture Clash

You'll like it.

Back in junior high school, I thought I was really smart, and intuitively good at math. I was blasting through algebra, and I loved to skip as many steps as I could while I worked the problems. This worked well until I later encountered proofs, and calculus. In calculus, I wasn't smart enough to skip many steps. In proofs, I skipped the wrong steps, to the annoyance of my teachers. I failed calculus in college and this was the beginning of my long descent into unpaid free software technical support. :-)

Luke, I don't want to be harsh, and am not trying to insult you, but you sometimes have the same problems with dealing with reporting problems. This was clear last week as I read both of the actual problem reports (debconf, X) You're smart. You understand a lot of the system. You'd rather skip steps, and cast around for laughable hypotheses (like the idea that gdm2 could break debconf). When you try to communicate what you've done to others, you don't show enough work to let them reproduce your mental state, you say things like "basically, dselect failed", instead of things like "I ran dselect, did this, and it gave this message about debconf failing, which I will paste in below".

So the resulting problem reports are the worst kind for me, as a Debian developer -- they don't quote error messages, they make wild stabs in the wrong direction as to what the problem might be, they do not try to help me reproduce the problem, and, when I ask for more information, I don't get it. I'd still really like to know the exact error messages for bug #181124, since I will be able to do nothing until I get them.

You really, really, need to read this essay. I hesitate to call this a "culture clash", but don't dispute the term either. You're certinly not alone in having this problem, though users on either side of you in experience seem to be able to report problems effectively, and get their bugs fixed 15 minutes after they're reported as a result. I'll bet you can too..

Anyway, to get away from you and back at the point of your article, is there a problem in Debian? Oh, probably. There generally is when this type of thing comes up. Fixes? Oh, better documentation, less harried developers, better orgnized documentation, better educated users, users who read. For all I know FreeBSD magically avoids these problems as grisha seems to suggest above, though I'd really like to know how. Most of your complaints have been made in general, about unix before.

My experience with Debian has a similar ring to it -- this is the first I have heard that apt-get was a developer's tool! I'm running woody on a PPC box, and in many respects, Debian and apt have been real life-savers. They have also driven me to the brink of sanity in a couple of cases.

My approach to dealing with this has been approximately to use apt to get anything that I don't intend to tinker with, and install the rest from source.

I understand this leads to conflicts with the packaging system, but to be frank, I think that packaging systems are a bit like GUIs -- if you're used to a command line (or building from source and managing these things on your own), a GUI (or packaging system) can seem like a real limitation.

Finally, I would like to thank the people that make Debian happen. It has become one of my favourite Linux distributions, and it is the first I recommend to others ('cause Slackware confuses some people). It's not perfect, but neither is anything else. :-)

Joey, while it's possible that lkcl posted uncomplete, unhelpfull, bug report, it does not explain why someone said that "apt-get is a developer's tool".

Is it really? If so, if nobody knows, who's guilty?

If not, it was an unappropriate answer. While answering to uncomplete (etc) bugs reports can be harrassing, it's important, IMHO, to answer in a more helpfull way. For instance, giving the link you provide would be better than leading the user to think that only a semi-god may use your software.

Apparently lckl didn't get the fact that the problem was the formal aspect of bug report that was problematic, and not his knowledge. Are you sure that the answer was unequivocal about that?

Finally, whatever the subject, it's always better to talk about technical issues or thoughts instead of persons.

I certianly did not say that. It was probably said in the xfree86 thread, although I don't remember the exact phrase. apt-get is becoming deprecated in Debian in favour of tools (aptitude) that use the apt engine but support recommends and suggests. We lost good handling of those when all the users moved to raw command-line apt, and it took some time to realize how significant that loss was (for example, it leads directly to the kinds of problems Luke had with X). This is a fairly new development that will be much more evident in the next stable release and many users are probably not aware of it. Which I suppose comes back to the idea of there being at least 2 subcultures in debian that can have trouble communicating with one-another.

(It's very hard to communicate ideas to all of our users in between releases. Bear in mind that it took about 2 *years* (and about that many releases) between the introduction of apt to debian and the big switchover of all of our users to apt.)

... I've started trying to mentally do an s/apt-get/aptitude/g on all my commandlines. The nice thing is that that actually works; the disadvantage is the mental reprogramming necessary. It would be nice if aptitude had a debconf option at a fairly high priority (or a low priority with the default as yes?) offering to divert apt-get to use it instead; as I understand it, they're almost drop-in compatible.

(except that, for some reason, aptitude doesn't seem to accept the -t option; that's probably an oversight?)

I understand that aptitude will be part of the base install in sarge - it would be even nicer if it was installed as apt-get by default, because it would save having to communicate with an awful lot of users.

Remember, developers are users too.... Anything in a tool that is obscure, irrelevant, counter-intuitive is simply because of bad design.

That's what KDevelop and many other projects are all about....

And granted, a "packaging tool" is the simplest kind of tool a developer would ever use, right?

I mean it....

> > xserver-xfree86 Recommends: xfonts-base - dselect and aptitude should
> > handle this correctly.
>  apt-get did not.
No, apt-get is an expert's tool, it's not designed for use by the
casual hacker.  If you don't know what you're doing, you should stick
with aptitude or dselect (preferably aptitude).  Otherwise you're
going to have this sort of problem over and over again.

sab39: probably something like that will happen eventually; aptitude is not 100% there as a complete drop-in apt-get replacement yet as you have noticed.

As people here seem to like aptitude I decided totry it instead of dselect. Well, it uses colors. Nothing bad in that, but it's so messy! I got a screen where aptitude tried to say something, I couldn't figure out what the reason for the screen was, but it was a huge messy page about the package libqt3 that somehow had some issues. There was huge amounts of information that basically told me nothing at all... Some parts are imho better than dselect, for instance the downloading progress is nicer to look at, but some parts are just a mess. :) I'll give it a few more tries though and actually read the manual (never needed to do that for dselect), maybe I can like it too.

What you're missing is that you can use aptitude just like you use apt-get, at the command line. No gui, no colors.

Yes, I was missing that, and it does seem to be a good replacement for apt-get. But I don't really use apt-get, unless I want to quickly install something really simple I know the name of. I normally use dselect, so I tried aptitude as a dselect replacement.

I looked at aptitude on the command line, and I was impressed. The dependancy and version info choices make it superior to apt-get. However, the default choice of installing every recommends/suggests items is a killer. That's one of the reasons I don't use dselect. I'm glad that I can know they are there, but don't give me 700MB for a 10k package.

I looked about, and I think there is a way to change the default, but bugs.debian.org seems to have a bug where turning off recommends/suggests installation causes their removal. Not pretty either. I think I'm going to wait until aptitude settles out and I can turn off automatic installation of recommends/suggests.

That said, why is xfonts-base not a direct dependancy of xserver-xfree86? I mean, if xserver-xfree86 cannot function without it (and it can't), it should be dependant, not recommended.

I'm laughing my ass off as you guys talk about those tools as if they were the product of some alien civilization....

You aren't serious, are you?

I didnt find -qq and -q (no, I do not want to read manual about -F right now), and it installed me checkinstall 1.5.3 while the package checkinstall was in hold status (I guess it's handled by a new method).

Aptitude is surely nice but: - why creating aptitude and not just enhancing apt-get (why apt-get cannot manage recommends? I guess that there are reasons for creating aptitude: any idea?) - currently, it's not possible to just replace apt-get by aptitude without reading a man page.

Sure, I will read the man page and I will use aptitude. But not today.

Also, if apt-get is deprecated, it should be printed at least when typing apt-get --help?

That's a matter of time, if I understand well. I think I use aptitude once "aptitude is 100% there as a complete drop-in apt-get replacement".

jibec: I have suggests turned off in aptitude, and have not experienced any mass removals. FWIW.

As to why xserver-xfree86 does not depend on xfonts-base, read the thread. Or just think about low-disk xfs clients.

hiya joey,

yes i am one of those weird people that does intuitive leaps of faith, and listens out for the "splat", climbs the cliff and tries the jump again. and again. eventually, by analysing the variations in colours and sounds, the right kind of leap can be found that hits the mark.

[empirically/darwinianilily] scientific? yep. provable? nope. people i have met absolutely HATE this way of thinking and doing, especially that it gets results REALLY drives them nuts.

sometimes, i cannot cope unless things are "in my face". i.e. error messages. obtuse error messages that make no sense lead me to try the above evolutionary style of debugging, until the error message goes away.

if the error message is obvious and helpful and recommends some advice, i'm happy: i'll go off and try the recommended advice!

also, some of the reports were from my brother, who has an IQ of 152 and _still_ doesn't get unix.

regarding the breakage of my brother's system, yes i can seriously confirm that his system's apt state could not be recovered until gnome had been reinstalled.

there was definitely something that had gone wrong, such that apt-get -f install would not fix the problem such that other packages could be installed; we didn't know that dpkg-reconfigure existed (in order to be able to tell dselect to stop using gnome); it was all quite distressing :)

If you're running unstable, and you type 'apt-get upgrade' or 'apt-get install', be conservative. Unstable often has inconsistent packages, and you can get yourself into trouble.

In particular: (a) watch for weird things being removed and (b) don't get so determined to install a particular package that you wind up uninstalling a bunch of stuff you really need. You may not be able to get it back without a lot of work and a good package cache.

Debian unstable works so well so much of the time that it's easy to forget that--in theory--it probably shouldn't work at all. I mean, some of your software might have been uploaded 5 minutes ago by a developer who made a mistake, and the only integration testing is all those other generous users of unstable. ;-)

Luke, every time I read one of your reports it really turns me off as a developer (not that I've got one from you personally yet, but anyway ...). I get plenty of bug reports from both experienced and inexperienced users and deal with (most of :-)) them just fine, so it's not that I have a problem with being told that I have a problem.

What it seems to be is firstly, as Joey said, you leave out the details and try to guess (often wrongly) at the problem. As Simon's "How To Report Bugs Effectively" essay says, would you, assuming you have no medical qualifications, do that to a doctor? They'd laugh at you and assume you were a hypochondriac, because sensible people give doctors the information they need and let them figure it out. Intuitive leaps of faith might work occasionally, but sometimes they're just way off: for example, you're still saying "we didn't know that dpkg-reconfigure existed (in order to be able to tell dselect to stop using gnome)" which makes no sense at all because dpkg-reconfigure has no influence on packages' dependency structure. All this kind of thing does is slow us down. Give the developers who know the software well the chance to make the leap of faith instead, where they're more likely to hit the target. What you're doing at the moment feels like there's a developer standing there waiting to jump off the diving board, except you keep running round and round saying "no, no, I want to jump again!" and diving straight into the shallow end.

But then, instead of coming up with more useful information when asked, you start ranting: in response to "could you send the output of what happens when you try dpkg-reconfigure debconf?", you ended up saying "what _has_ come out of this that is clear is that debian is very dangerous for inexperienced users to play with, because they can get into a right mess unless it installs perfectly first time."

What good does this do? Not only do you not provide any useful information (well, perhaps you can't, you said it was second-hand) but in response to the developers who are sincerely trying to help you you implicitly rubbish everything they're doing. Oh, certainly you have "I love Debian and want to help" disclaimers, but that's not what your words are saying, maybe unintentionally. Such comments are more likely to be demoralizing than motivating.

Would you consider this request? Please keep bug reports limited to the technical discussion. Drop the comments about how critical it is for ordinary users, about how all us developers are so used to the system that we don't see the big picture, or whatever. Just report the problem with as much information as you can muster, and leave it at that: a simple rationale for why you want something is OK, but don't go overboard. When asked for more information, either provide it or say "I'm sorry, I can't manage that right now". I suspect that on average you'll get a much better response.

Opinions and philosophy belong on mailing lists or forums like Advogato. Bug reports should be restricted to technical discussion wherever possible.

(No offence meant by any of this, obviously. I just want to see the quality of bug report discussions as high as possible, since that's better for everyone.)