On Mon, Nov 03, 2003 at 09:59:24AM +0100, Bill Allombert wrote: > Choose one: > > The first is to add a debian/rules.version with meaning: > debian/rules.version is present and is "1\n": build-arch and build-indep > are implemented > > The second is to add a debian/rules.targets with the list of available > optional targets. > > First solution is easier to implement. Second one scale better but does not > allow to revoke the meaning of a target. > > If you are going to second this proposal, please state if you prefer > debian/rules.version or debian/rules.targets. I like the general idea, but I prefer neither name. Why are we attaching a versioning concept only to the rules file? I think we should attach versioning to the entire layout of the unpacked source package. This gives us the flexibility to make other kinds of changes without cluttering debian/ with still more files. Consider a file debian/format: $ cat debian/format rules: 1 control: 2 The above tells dpkg that the package in question is using version 1 of the debian/rules specification, and version 2 of the debian/control specification. (We could retroactively define version 2 of debian/control as one that permits comments, for which dpkg recently added support.) The debian/format file can be extended arbitrarily to suit our needs. We could change the format of a debian/changelog file with this technique as well, if needed. Of course, version 1 is assumed for everything in the absence of a debian/format file. Comments? -- G. Branden Robinson | Lowery's Law: Debian GNU/Linux | If it jams -- force it. If it branden@debian.org | breaks, it needed replacing anyway. http://people.debian.org/~branden/ |
Attachment:
signature.asc
Description: Digital signature