In article <[EMAIL PROTECTED]> you write: >Gordon Matzigkeit <[EMAIL PROTECTED]> 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...
