Re: [RFC] Package build time config for installation directories.
On Mon, Nov 06, 2000 at 03:19:40PM -0600, Steve Greenland wrote:
> On 06-Nov-00, 13:35 (CST), Ben Collins <bcollins@debian.org> wrote:
> > On Mon, Nov 06, 2000 at 10:58:30AM -0600, Steve Greenland wrote:
> > >
> > > 1. "Non-FHS ports". This seems to me a contradiction in terms. Marcus
> > > has weighed in with "but HURD *is* FHS", and I don't see why other ports
> > > can't be as well, especially as HURD is the least unix like of the
> > > listed OS's. If it can't be made FHS compliant, then perhaps it's not an
> > > appropriate target for a Debian port. What's next, and NT "port"?
> >
> > Hurd is probably not the best example...so I retract it as one.
>
> So what about the others? Why can't they be FHS compliant? If they can't,
> why are people
>
> a) attempting to port Debian to them?
> b) expecting every other developer to accomodate their weird needs?
I did not know Debian was strictly an FHS project. When did this happen?
Did it creep into the Social Contract while I wasn't looking? Maybe we
could get away from this centered view if we weren't so dependent on paths
of this kind. Also, future changes (like the /usr/doc and games dir) would
not take so much effort if things are configurable in this way. IOW, we
reduce long term effort by supporting this short term effort.
> > > 3. "Third-party stuff". Don't care.
> >
> > Third-party != non-free OS, so I hope that isn't the basis for your
> > opinion. Dpkg and Debian policy is a fairly powerful tool that I would
> > hope extends well beyond just "us". If this benefits them, it is a plus,
> > not a "ooops, oh well".
>
> No, it's not that it's non-free, it's that I do not understand why I
> and every other developer are being asked to modify our packages and
> possibly the upstream source in order to support people who are not
> using Debian systems. I don't see "support our packaging system on
> arbitrary systems" anywhere in the project goals.
>
> Yes, if someone outside the project benefits from the work we do, that's
> great. But doing work to benefit those outside the project (and by
> "project", I mean our users as well, of course, not just the developers)
> rather sticks in my craw.
>
> So yes, if this is necessary to support the various 64bit ports, then
> great (even after your explanation, I'm not sure that it does, but I
> don't know enough to argue, so I'll let others do it :-)). If not, then
> pushing the benefits to non-Debian system users doesn't mean a whole lot.
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. Dpkg is
slowly being developed so it can be run on non-linux systems (and even,
*gasp*, non-free ones).
Now, if you don't like this reason of third party OS's, then skip it. I
listed several scopes of where this would help, hoping to cover a lot of
concerns that our developers and users have (even if they aren't your
concerns). Look at the benefits that affect you and the ones you are
concerned with.
Now as for 32/64, I do know it will help. I'm not sure that there are any
other Debian developers that have looked into this as deeply as I have,
and considered all the design problems preventing it from happening in an
easy and maintainable manner. In fact, RedHat's package management for
ia64/sparc64 is (admittedly from some one involved with the setup) quite
hackish and doesn't really work. This issue was my main reason for coming up
with this proposal. 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.
--
-----------=======-=-======-=========-----------=====------------=-=------
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` bcollins@debian.org -- bcollins@openldap.org -- bcollins@linux.com '
`---=========------=======-------------=-=-----=-===-======-------=--=---'
Reply to: