Re: DRAFT: Fixing the architecture query options of dpkg.
Hi,
A lot of this proposal seems to be about providing the rules
file a means of determining the details of OS/CPU of the build and
target system to aid in cross compilations. It deals specifically
with the distinct parts that make up a string that GNU builds use to
distinguish target types.
I am fairly convinced that this should be a stand alone
program, and not built into dpkg. dpkg knows enough to function as it
should, and we should not overload dpkg with yet another
functionality. (I know that dpkg started all ths by providing a
rudimentary facility, but as Marcus points out, that is not quite
enough, and we need a more sophisticated program that handles this
which can be used in rules files, and on non-debian systems as well)
>>"Marcus" == Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:
Marcus> Problems
Marcus> ========
Marcus> We see that there is neither a clear seperation of OS type
Marcus> (gnu or linux), nor a clear seperation between target and
Marcus> build system type.
Why is this a problem for dpkg? And why should it be dpkg
providing this information, as opposed to something less critical to
the package management system, like a stand alone faclity?
Marcus> Proposed Options
Marcus> ================
Marcus> --print-installation-architecture
Marcus> Stays the same. (Later, we can make it returning a _list_
Marcus> of installable Debian Archs. This is for systems which
Marcus> support multiple Debian ports, like sparc64 (supporting
Marcus> sparc) and pentium (supporting i386), or even hurd-i386
Marcus> (supporting i386 with Linux binary compatibility)
Returning a list would break all rules files that use the dpkg
facility --print-installation-architecture. Such gratuitous
incompatibility is unacceptable.
Marcus> --print-target-installation-architecture
Marcus> Returns the target Debian Arch for package
Marcus> building. Normally, this would be the same as
Marcus> "--print-installation-architecture" (default), but for
Marcus> cross compilation, you could change dpkg (for example by
Marcus> diversion) to return a different Debian Arch.
This is a bad idea. This means that one can only cross compile
for one arch at a time, without dealing with diversions. Two people
on a master compilation machine can't work at the same
time. Currently, the target information is garnered using the GCC
which is in play at the moment (we change which gcc is being used by
setting env variables and paths, etc, and that mechanism permits
simultaneous compilations targetted at different architectures)
Marcus> --print-gnu-build-architecture
Marcus> --print-gnu-build-os
Marcus> --print-gnu-target-architecture
Marcus> --print-gnu-target-os
All these should be better put into a stand alone
binary/script that is dedicated to just this, and not in dpkg.
Marcus> Rationals, consequences etc =========================== The
Marcus> changes that are needed would be minimal. Adding the options
Marcus> to dpkg, and changing the building scripts in dpkg-dev to use
Marcus> --print-target-installation-architecture instead
Marcus> --print-architecture would suffice. No further changes are
Marcus> _required_.
How is all this not addressed with even less impact by not
mucking with dpkg at all, but providing a new facility that is
available to package maintainers?
Marcus> If no one has serious concerns, I will make this an official
Marcus> proposal, soon. For now, I just want to gather some more
Marcus> information. For the official proposal, I will have to dig
Marcus> out the relevant sections in our policy and provide
Marcus> replacement text.
I do have, well, concerns, and would appreciate a technical
argument why modifying dpkg is a better idea than providing a stand
alone facility that would allow simultaneous cross compilations to
occur (I really used a system like this; with DFS mounted source
tree, and simultaneous compiles of the same source code over 5
different UNIX machines. I see no reason to compromise that
functionality).
manoj
--
Sank heaven for leetle curls.
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Reply to: