Fink:Packaging:Fink on multiple architectures

Recent versions fink contain support for multiple-architecture distributions (unified .info files) by means of a new "Architecture" field. Dmrrsn's proposal that we adopt this new field starting with the 10.4 tree, and that we get this into released fink versions "very soon", has been implemented.

For ease of initial setup and migration of existing packages to new architectures, this field has a default value of "powerpc, i386"; for packages which are only appropriate for one architecture or the other, a value could be specified. For example, any package using a compiler earlier than gcc-4.0 should have "Architecture: powerpc" added to it. We now have a wiki page to help track tagging with this new field.

(The tags "powerpc" and "i386" are the correct ones coming from uname, which are used in the name of binary-darwin-foo directories. One question is whether we should allow alternates like ppc which fink would translate.)

Note that this mechanism is very flexible: if we ever have a third architecture, we can just add a third tag.

The indexer only indexes those packages whose Architecture field (or its default value) contains the current architecture. That is, "if an Architecture field is present, only index the file if local architecture value is listed".

If a package needs separate info files for different architectures, they can be given names like foo-powerpc.info and foo-i386.info. If the version/revision numbers also need to be included, the name could be foo-powerpc-1.1-1.info and so on. The .info filename is not parsed for any metadata (any *.info will be read). To simplify validation, the location of the archname within the filename is now fixed: the validator accepts the invariant packagename, optionally followed by archname, optionally follwed by distribution, and finally optionally followed by either version or version-revision, each delimited by hyphens.

We have a tag already for the current architecture: %m. This can be used in forming names of patch files, for example. That also means we can use the existing variant mechanisms and shell logic tests to support Platform-dependent differences in a single .info file. Note that compiled packages are not portable among different architectures (the arch string is part of the .deb filename and control-file metadata), and DMacks doesn't think there is a need to worry about "upgrade paths" among platforms. That means a package that contains platform-dependent differences does not need to have a different revision on each platform or contain %m in the Package field.

Vasi pondered using this opportunity to add a Distribution field as well, since it would have the same indexer-exclusion behavior. If we're gonna have a consolidated tree, let's not be pansies about it. If we needed needed Distribution-based differences for a package, we would need a new %-exp token and also a way to have different Revisions for different values (or else some other way to make the Distribution visible in debian metadata). Also need a way to have different subtypes (conditionals on Type key values, for example, a -pyXX package only has XX=2.1 on distro <= 10.3). But until we figure out a syntax, could just say "if you need different revision in different Distributions, make separate .info files. Seems reasonable...

So should we go for a unified tree right now? Should it include 10.3 as well as 10.4? Dmrrsn