Re: [RFC] Package build time config for installation directories.
On 06-Nov-00, 16:18 (CST), Ben Collins <bcollins@debian.org> 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 <stevegr@debian.org>
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)
Reply to: