Your reasoning, guys, is largely sound and I can't say I disagree all that much. In the long run I believe in choice first and convenience second, but sufficiently large convenience overrides insufficiently large choice. All I know is that, from a personal perspective, I don't want extra **** being installed when I don't need it just because someone else does, but at the same time, I don't want to impose inconvenience to others. (You know how asterisk depends on bash? Well, lately I've been tempted to recode anything in it that depends on bashisms into a straight bourne compatible shell just because I find the need to have bash on my N900s very irritating. But I digress.)

At the same time, I actually DO think that it's not a bad thing to do provides, and if it doesn't work, have users install the 'real' package instead. I maintain alpine for instance for those who don't remember, and I really feel tempted to add a 'provides nano' so that things don't install it when it's already an almost-compatible editor at least in the general usecase. But sure, maybe that's too confusing or whatever for other people, and it'll screw the tech-unsavvy more than the tech savvy ones. So I get it.

My suggestion is, do 'provides' for virtually feature-identical packages. Is there really anything to 'less' that our 'less' doesn't provide? Or, MORE fairly but harder to quantify, does busybox-power "less" provide the feature-set that a normal person can expect on a normal Unix/Linux system? If it meets either of these criteria, I think the provides should be right in the packaging of busybox-power. IF, on the otherhand, busybox's, say, tar, provides far less features than the GNU tar, then it shouldn't do a provides in the main packaging, and in that case we get around to discussing this.

I really like this idea. This is great in my opinion, it lets people have the best of my initial suggestion (and some of the bad parts), but it's a /chosen/ tradeoff and not imposed on anyone.

On that note, I was actually already thinking of doing this, and I think this is the path I'm going to take when I have the spare time to make some packages and push them to devel: 'fkdeps-xyz', where 'fkdeps' stands for either 'fake dependencies' or '[english cuss word beginning with 'f'] dependencies', depending on how you want to interpret it and how angry you are at unnecessary dependencies (for historical purposes, for me it meant the latter first, morphed into the former later), and 'xyz' is the name of the given package that that fkdeps package provides.

This way, we can have granular fake dependency-providing packages, in a generic name and not tied to any specific package, allowing packages that truly 'provide' a feature to only provide the ones they can clearly say they provide but also allowing users who don't want dependencies to be pulled in to....

...even better idea. I'm going to make a shell script called fkdeps (alternative name ideas welcome, I'm also considering the name "equi", since there's a Debian package called "equivs" which is a more feature-ful and more dependency-having tool of similar purpose), which will use the minimal tools it can (no dependencies on anything that isn't already on the N900 if at all possible) to create a fake deb package that provides the package name specified. I'll (someday) also give it a hard-fake option, to generate a package with the same name as the faked package, because that's the only way to fake a specific version and thus (because 'provides' is always unversioned) the only way to fulfill a versioned 'depends'. No fkdeps-* package bloat in the repos then.

Good talk.