Re: DRAFT: Fixing the architecture query options of dpkg.
Hi,
On Thu, Jan 07, 1999 at 03:40:13AM -0600, Manoj Srivastava wrote:
> 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.
Exactly. My main concerns are the rules files and the developer scripts.
Cross compilation comes to mind, but also important is that we can determine
the full GNU System because we now have two supported operating systems
(linux and gnu).
> 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)
I am fine with this solution, indeed, I think it's better than changing
dpkg. The reason I proposed to change dpkg is that dpkg provides the
functionality currently, which is probably not a good idea at all, as you suggest.
Using a seperate tool for this has several advantages, as long as this tools is
added to dpkg-dev and we can use it in the rules files (so this additional
tool should be required, and not optional, for package building purpose).
> 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.
Right, I realized that later. It was just a side remark anyway. Please
disregard the text in parentheses above.
> 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)
Okay, I can see your argument. It is connected to the "why use dpkg"
argument. My original point is that you need a way to find out the target
Debian Arch name at build time. dpkg-cross makes "dpkg-buildpackage"
supporting an "-a" option to specify the Debian arch. But currently, there
is no way to pass this to dpkg-buildpackage and friends, and packages are
build using "dpkg --print-architecture". Therefore, I change my proposal:
dpkg-buildpackage and friends should support an "-a" option to pass the
Debian Arch string which should be used to build the package and the changes
file. What should be the default if no -a option is given? Well, I think it
should be "dpkg --print-installation-architecture", as we need a valid
Debian Arch.
--print-architecture would become obsolete. Maybe it is just that I don't see
what it does and for what it is useful. Anyone knows for what it is needed?
> 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.
Agreed, if we can rely on this scripts in the rules files (that means, if
the script is included in dpkg-dev).
> 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?
Sorry, it was just my lack of imagination. But this is the reason why I send
a draft, so people can point out to me my obvious mistakes :) Now, after
reading your mail, I could clap myself on the forehead for not thinking of
it...
Do you agree that "dpkg --print-architecture" and "dpkg
--print-gnu-build-architecture" would become obsolete when we have the new
script (and only is provided for backward cmpatibility)? If there is still a
real need for them, I would like to know (not that I have any plans with
them, I would just like to now if I am missing something).
> 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).
Your points are well taken. If you agree with the basic functionality of the
new script, I will start a first implementation soon. Also, my proposal
needs to be rewritten.
The other point is my new proposal to specify the target _Debian_
architecture at build time with the "-a" option (as it is currently
used by dpkg-cross), so that the dpkg-dev scripts know about it.
Does it sound better than the (now obsolete)
--print-target-installation-architecture? Have you an even better idea?
Thanks for your help, it is much appreciated,
Marcus
--
"Rhubarb is no Egyptian god." Debian GNU/Linux finger brinkmd@
Marcus Brinkmann http://www.debian.org master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de for public PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Reply to: