Re: [RFC] Package build time config for installation directories.
>
> 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.
Well, let's not take the opposite approach and assume that just because a
solution provides benefits outside the main scope, it is the wrong one.
Being too specific to a goal, is what causes problems. Usually there are
several issues that have the same general causes, and can be solved with a
general solution such as this one.
1) We cannot assume that the directory structure of Linux/Debian will
always remain the same.
2) Given #1, and the fact that we have seen how much effort is required to
satisfy single directory structure changes, I think defining them
programatically in a central localation will have a lot of benefits for
future changes. Easing transistions by simply recompiling, etc..
Now if it makes you feel better, maybe we should have a default of
"dirs.fhs", and supply alternatives to override them for the 32/64 ports.
> 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.
Of course they wont supply patches for all of them, because it would be
an insane amount of effort for a handful of people. On top of that, these
library maintainers would eventually have to accept patches for sparc64
and possibly mips64 and powerpc64, in addition to ia64. Something I'm sure
they would get tired of, and make things horribly specific and prone to
breakage, and not very central. On top of that, we all know that package
maintainers are generally focused on their package, and not
characteristically concered with others agenda's (not in a bad way, but
let's face it, not every library maintainer really cares about getting an
ia64 or sparc64 patch out the next day, so the porters have to wait on
some else, for every case).
Now, if this were implemented, and say it was only implemented for
libraries, each of those maintainers would have to make a nominal amount
of changes, *once* and only *once*. I'd say that is a benefit, and a far
better solution. 25% of Debian is a rather large portion to worry about
porting, and providing patches for. Some may say "so what", but do we really
want to limit Debian's architectural scope because of this? I surely
don't. Do we really want to diversify the implementations of this on a
per-package level? Not really, not on this scale.
Yes, as I said this is only part of the issue, but it is a major one. With
this I can actually make a complete sparc64 port available to use, with
strictly 64bit. The reason being that all 64bit libraries for sparc ABI
must go into /lib/64:/usr/lib/64, so that it can run on other
sparc64-linux systems. So even if they can't install sparc (32bit)
packages on top of this, it is still 50% of the battle.
Yes, getting the 32bit overlay would solve the rest of the problem, but
that does not involve packages, it has to be handled in the package
manager and package build scripts. I can go into the detail of that, but I
prefer to remain on target for this specific goal.
--
-----------=======-=-======-=========-----------=====------------=-=------
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` bcollins@debian.org -- bcollins@openldap.org -- bcollins@linux.com '
`---=========------=======-------------=-=-----=-===-======-------=--=---'
Reply to: