On 06-Nov-00, 16:18 (CST), Ben Collins <[EMAIL PROTECTED]> wrote: > Did we forget that these program are not created for Debian, and the > majority of them are not even created soley for Linux? I wonder if that > has been lost in this self-centered view that Debian/Linux(or FHS if you > want) is the center of all free software authors design goals.
Not at all. However, the Debian packaging system was designed to meet the needs of Debian users and developers. To suddenly say we want to accommodate other systems seems like a sudden scope change, without much discussion. FWIW, I've made several changes to my packages to accommodate HURD, and have no objection at all, because HURD is part of our effort. > Dpkg is slowly being developed so it can be run on non-linux systems > (and even, *gasp*, non-free ones). The Dpkg developer's are free to do as they please: it's their effort. This in no way implies that all Debian packages need to build on all systems that dpkg runs on. One of the good things about our system is that policy is (mostly) divorced from the tools, especially the lower-level ones. I can do whatever I want in the rules file, and so long as I stick the result in a tree, dpkg-deb will build it up. Follow a few more rules, and dpkg-buildpackage will be reasonably happy with it. If non-Debian systems need different policy, that's fine. But a policy with no standards is pretty much the same as no policy at all. And a policy full of if-then-else clauses is worse. > ...After looking at it, I noticed there are some other benefits of > doing it this way, which is a plus, not a downside. It's always > good to get extra functionality from one plan. Now designing this > so we prevent those benefits based on trivial ideals of who we want > to benefit is not only reducing the generalization of a proper > implementation (so as not to be so specific that it can't solve other > problems that may arise within the "project") but is suicidally > idiotic, to the point of monopolistic tactics (we only want our users > benefiting, not yours). So let's not play into that scenario please. That's not what I want, and if I've implied so, I didn't mean to. I'm not asking that you design to avoid helping others. I'm asking that the design not be overly onerous on our developers solely to aid those who are outside the Debian Project's scope. We can't be all things to all people. A solution that completely and correctly solves the 64bit port problem is the right thing to do. Both you and Jason seem to agree it only affects libraries. Both you and Jason agree seem to agree that dealing with the directory locations will not solve the whole problem. That tells me that more thought needs to go into the solution. Ben, you may well be the most qualified person in Debian to create the right solution. But consider the long-term imposition that you're putting on all the packages to partially solve a problem for less than a quarter of them[1]. Even if the ia64 people go nuts and supply a patch for every package that needs it (which I certainly don't expect them to) it adds complexity, which is another weak point for stuff to break. Okay, I've had my say on this subject, I'll shut up. Really. Steve [1] On a current woody system: speedy:~$ apt-cache pkgnames |grep lib |wc -l [2] 1758 speedy:~$ apt-cache pkgnames |wc -l 7649 1758/7649 ~= 0.23. [2] Yes, I know that's not a perfect count on the true library packages. Deal with it. -- Steve Greenland <[EMAIL PROTECTED]> (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
