Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
On Mon, Nov 03, 2003 at 11:35:48PM +0100, Santiago Vila wrote: On Mon, 3 Nov 2003, Andreas Metzler wrote: [...] [1] Currently this is only possible with ugliness like making build-indep an empty target and doing the actual expensive work in binary-indep, Some of the packages I maintain use texi2html in the binary-indep target (and they have texi2html in Build-Depends-Indep). Why is such thing an ugliness? It is because it runs under root/fakeroot or are there any other reason? Personal taste. ;-) iMvho it is obviously ugly, if the makefile has build-indep and build-arch targets, I exspect that the time-consuming activities are done in it. But the real ugliness is that current policy propagates implementing build-arch and build-indep target although they are useless. I _would_ really like to see either these two targets made useful (using something like Bill's proposal) or to abolish mentioning/suggesting them in policy. or ignoring policy's recommendation to make build depend on build-arch and build-indep. Which is what I would call complexity for very little gain. Packages which do not benefit from a split build-arch / build-indep (and there are certainly a lot of packages which do not benefit) Ack, I am completely with you. (None of mine does.) should continue to be allowed not to have such targets, without people or policy saying they are following a deprecated format or anything like that. Does this clarify my point? Yes. And I agree. I just want the existing build-arch and build-indep target made useful. What about optional fields in the control file with default values: Build-Arch: build Build-Indep: build (and therefore may be omitted), but that can be overridden in this way?: Build-Arch: build-arch Build-Indep: build-indep only for packages which really need or benefit from them? (What I dislike is a format version, mandatory conversion of all packages to the new format in the long run, and all that). That is equivalent to Bill's second proposal. I get your point and support it. cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash
Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
On Tue, Nov 04, 2003 at 12:32:47AM +0100, Bill Allombert wrote: On Tue, Nov 04, 2003 at 12:10:19AM +0100, Josip Rodin wrote: What mandatory conversion to the new format in the long run? As I see it: currently there is version 0 and 1. Suppose one day version 2 is added. Requirement for version 2 will include requirement for version 1. If you want to implement version 2, you will have to implement version 1 even if it is not useful, say for a Arch: all source package. However, if you don't need version 2, you can stay to version 0. As a parallel, some of my packages are still using DH_COMPAT=1 debhelper interface, and no one is complaining. Although I keep seeing inexperienced developers converting packages to debhelper version 4 in NMUs. :-/ It's newer and shinier, so it must be better, right? (And I wonder how many versioned build-deps on debhelper go missing in the process, how many duplicate conffiles get created by incautious moves to DH_COMPAT = 3, and so on ... there's a reason we discourage cosmetic changes in NMUs.) If we're adding optional features, doing so in a way that doesn't confuse people into believing that all packages need to use them would definitely be a good thing, I think. Cheers, -- Colin Watson [EMAIL PROTECTED]
Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
On Tue, Nov 04, 2003 at 12:32:47AM +0100, Bill Allombert wrote: (What I dislike is a format version, mandatory conversion of all packages to the new format in the long run, and all that). What mandatory conversion to the new format in the long run? As I see it: currently there is version 0 and 1. I'd rather start with 1 being the current version (0 would indicate some pre-production level, which it certainly isn't), but anyhow. Suppose one day version 2 is added. Requirement for version 2 will include requirement for version 1. You don't necessarily know that. -- 2. That which causes joy or happiness.
Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Josip Rodin wrote: Well, regardless of whether we pick versions or listing available targets, why not do it with a new control file field in the source section? That seems logical, and avoids creating a new file. It's tangentially relevant that the .dsc and .changes files include a Format field that is a version number. Having a Rules-Format: 2 field in control seems okay to me. I agree that this would be the way to go (though I'm ambivilant about the proposal). -- see shy jo signature.asc Description: Digital signature
Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
On Tue, Nov 04, 2003 at 02:04:27AM +, Colin Watson wrote: It's newer and shinier, so it must be better, right? If we're adding optional features, doing so in a way that doesn't confuse people into believing that all packages need to use them would definitely be a good thing, I think. I agree that this may become a problem. Can you suggest a better way? Maybe list tags within the new field rather than using a number? -- 2. That which causes joy or happiness.
Bug#218893: Alternative proposal: debian/format
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 [EMAIL PROTECTED] |breaks, it needed replacing anyway. http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
On Tue, Nov 04, 2003 at 06:34:23PM +0100, Josip Rodin wrote: On Tue, Nov 04, 2003 at 02:04:27AM +, Colin Watson wrote: It's newer and shinier, so it must be better, right? If we're adding optional features, doing so in a way that doesn't confuse people into believing that all packages need to use them would definitely be a good thing, I think. I agree that this may become a problem. Can you suggest a better way? Maybe list tags within the new field rather than using a number? That would be a solution. Just find a tag that mean that build-arch and build-indep are implemented, but shorter. Maybe split_build. And add Build-Options: split_build in debian/control. Build-Options being a comma-separated lists of implemented options. Though I start to wonder whether the original rules.targets proposal was not cleaner. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here.
