Re: Debian GNU [was: smarter way to differ architectures needed?]
In article <[🔎] 87soa6ug5d.fsf@cush.dyn.ez-ip.net> you write:
>Gordon Matzigkeit <gord@trick.fig.org> writes:
>
>> BM> When the source package is compiled, the appropriate items from
>> BM> the "Nonshared-depends" would get moved to "Depends".
>>
>> Or, equivalently, the `||' symbols in the Depends field would be
>> replaced with the dependency that was actually used.
>
>I have to say I really prefer using a different field for this; I
>might go so far as to suggest that on compilation those dependencies
>which come from the "Nonshared-depends" field (I'm not wild about that
>name, but I don't have a better idea myself at the moment) go into a
>new field, to ease in transition to the new system.
I once thought the way you do, but since discussing the matter,
lately in private with Gordon, I tend to agree more and more with
him. This is because his method is simple to implement and
I can no longer see any major problems/limitations with it. (there are a few
minor issues I have raised with him, but nothing serious).
Like Gordon said, you have to break the old mind-set of thinking of
"arch-depends" and "depends" as seperate issues, when it fact they
are becoming very similar concepts. (ie if a package compiled for
"arch-i386" would run use to depend entirely on the archiecture of the
destination computer. Now days, it can depend on if emulation software
has been installed or not. Of course, the native code is always
preferred.).
>Of course, this is assuming that anyone actually wants to code the
>implementation of this...
I think the implementation should be easy. I will list *MY*
interpretation of the changes I think are required. Gordon (or anyone
else), please tell me if I have got something wrong.
A. Source packages. architecture is no longer supported (except
for backword compatability). Depends is now used instead. When
compiling the package:
A1) Check if architecture field exists. If the value is all[0], replace
it with the null string "". Otherwise append "arch-" to the start.
Insert the result into the depends line. Seperate entries with ",".
Example: "Architecture: any" would become "Depend: arch-any, ...".
A2) Expand the depends. This involves replacing keywords like
"arch-any" with "arch-i386 || arch-sparc || ...". How should
these expansions be stored? This is an issue I have not yet
discussed with Gordon, but I think for the time being
it should be safe to hardcode it in a configuration file
associated with the tool that does the expansion. There
should be no reason for it too change it too frequently,
but if anybody does want to change it, it should still
be possible. Anyway, the values here are only relevent
when compiling packages and won't be used afterwords.
Example: "Depend: arch-any, ..." would become
"Depend: arch-i386 || arch-sparc || ..., ..."
A3) Check the depends line for any "||" and replace the entire
section (seperated by ',') by the value used by the current archicture.
Should "|" (or) still be supported? That is an issue I have
raised with Gordon.
Example: if compiling on i386, the above would become
"Depend: arch-i386, ...". This is a standard "depends" line
and doesn't require any special parsing.
I think Gordon was saying if "|" is not supported, "Provides" would be
used instead.
I think it would be simpler, at least in the
short term to support both "|" and "||", but not in the one
section. ie
Depends: arch-i386 || arch-sparc, lynx | netscape
would be OK and on i386 would be translated into
Depends: arch-i386, lynx | netscape
BUT:
Depends: arch-i386 || arch-sparc | arch-somethingelse
would be illegal as it is ambiguous. Sure, there are ways
around this (ie use brackets) but I don't see any real need.
Please tell me if I am wrong (give examples too).
This minimizes the amount of change required. I don't see any need
to remove support for "|".
Also, some names need to be given. I previously thought
of using "os-any" to mean "hurd || linux || ..." but Gordon disliked
it. What is a better name? "kernel-any"?
"idontknowwhatthisfieldshouldbecalled-any"? ;-)
B. Binary packages. architecture is no longer supported, but if
it exists, it should be used as well as depends. ie the only
change required is dpkg not to display a warning if the "architecture"
field is missing (I think).
C. Packages would have to be installed to provide packages like
"arch-i386", "linux" and "hurd". Would these need protoection
against installation on incompatable architectures? If so,
this could be done via a combination of "depends" and/or
preinst routines.
D. Archive reorganisation. This is something we haven't discussed yet.
I think it is going to be the worst problem (when we get to this
stage). I won't even attempt to go through all the issues I can think
of yet.
--------------
Notes: All of this is long and may appear to be more complex then it
really is. Steps A1, A2, A3 could be implemented, for instance, as extra
debhelper method(s)[1][2]. This should be dead easy for somebody with the
programming experience. Then the only other change required is to ignore
"architecture" if it doesn't exist in steps A and B (how hard could this
be?) and then do C (also easy) and D (yet to be discussed).
[0] for my example I have ignored the question of how to assign
the value of "linux" and/or "hurd" to old packages that use the
"architecture" field. This would involve changing step A1 as required.
[1] details of minor issues ommitted, eg how to expand "arch-any"
without altering the contents of the orginal control file, but still
pass the contents on to other tools that require it.
[2] Implementing it as debhelper methods has the advantage if somebody
doesn't like the way we have done it, they can design their own way...
Reply to: