Fink:Major New Feature Plans:NonAutomatic field

As a step towards building a better system for automated testing of Fink packages, I propose a new field, "NonAutomatic", in .info files to designate those packages that cannot be built automatically. The comma-separated values listed in this field would be limited to just a few prescribed ones (like the License field), to be enforced by the validator. When the field is used, the reason for it should be described in DescPort or DescPackaging.

The following are the initially-proposed values:

• AquaRequired

To be used when compiling requires access to a running Aqua window manager. There are 12-15 such packages at the moment.

If instead we had a system-aqua-display virtual pacakage, we could just BuildDepends on that and then fail due to the usual missing-dep mechanism. This would be useful even in for non-automated builds. User:Dmacks is working on it (thanks User:msachs for the code!)No, because display accessibility might be different for root (via dpkg) than for CompileScript (due to --build-as-nobody). Would have to have added magic for that BuildDepends value, at which point it would be less confusing to have a different field for this different behavior.

• X11Required

This is more often encountered during package self-tests, but it's sometimes seen in ./configure and it could be hard to patch around it. Alternately, we could have a system-x11-display virtual package.

• HumanIntervention

To be used when the package requires human intervention either to build or to install. For example, a person might need to interact with a postinstall script the first time the package is installed, or a non-free License might need to be accepted as the package is compiled. (Human intervention in the building and installing of packages should be avoided whenever possible, and maintainers should discuss the need for it in fink-devel before creating/committing packages which need this flag.)

• ExternalResourceRequired

To be used for various system-foo packages that cannot be built or cannot be installed unless a resource external to Fink is present. (This includes mac-growl-pm*, which requires an external installation of GROWL, for example, even though the word "system" does not appear anywhere.) To be clear about this: the non-external resources will be those things available from Apple. This means XCode including all compiler packages, the gcc-legacy stuff on the powerpc platform, and X11 (including the SDK).

• RootRequired

To be used for packages that cannot be built in --build-as-nobody mode. There are still a handful of packages that fail to build (or build incorrectly) in this mode, but this mode is important to protect the integrity of the autobuilder system itself. Maintainers should fix packages to work as nobody whenever possible.

• NetConnectionRequired

To be used for packages that cannot be build without an active network connection. (Suggested by ChrisDolan)

I don't particularly like the above names, and would be happy if someone could think of better ones! Maybe drop "Required" from the value strings to make linguists happy?

1. Good idea, but then maybe the field should be called "OtherRequirements" with possible values "Aqua", "HumanIntervention", "ExternalResource", "Root", or "NetConnection". Dmrrsn

Questions:

1. How should we handle packages that have dependencies on these packages? If foo is NonAutomatic:ExternalResourceRequired and bar:Depends:foo, should bar be: 1) NonAutomatic:ExternalResourceRequired, 2) NonAutomatic:NonAutomaticDependency, or 3) not tagged explicitly?

   I say it should not be explicit, so that if foo changes its behavior, then bar doesn't need to be updated. If we care, then Fink can propagate this data at runtime. ChrisDolan

   I concur (and I think drm's on board too after discussing it in #fink). In addition, if builder doesn't attempt to build pkg because it is flagged, we only learn that it is flagged. If it doesn't build because a dependency could not be built for whatever reason (maybe it's flagged, maybe it's just bugged) we learn where to look to start resolving the issue. DMacks

   Let's think about an example here. The package system-tetex is designed as a placeholder for people who have installed Gerben Wierda's tetex distribution. It builds automatically OK, even when the external tetex is absent, but can't be installed. However, the package xdvi-system-tetex, which is essentially a variant of the xdvi package to work with system-tetex, can't be built because it has a builddependency on system-tetex. Which of these should be flagged?

   Another, similar, example: a package called system-viha which is a placeholder for an external resource, which can be built but not installed if the resource is absent. And then there is the package "kismet" which won't build unless system-viha is installed. Same question: which of these should be flagged? Dmrrsn