Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition
Wouter Verhelst [EMAIL PROTECTED] writes: Therefore, if the implementation of sbuild differs from whatever Policy happens to claim, then Policy is simply wrong. As state before policy is wrong. That doesn't mean we can't change both policy and sbuild at the same time to something that both reflects current practice and adds room for improvements. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition
Manoj Srivastava [EMAIL PROTECTED] writes: On 18 Jun 2006, Goswin von Brederlow outgrape: Peter Eisentraut [EMAIL PROTECTED] writes: Goswin von Brederlow wrote: On the other hand the savings can be huge. Think about how many packages install latex and fonts and generate the documentation needlessly during build. Installing and purging latex as well as all the initex runs and font generation takes up a awfull lot of time I think most packages build their documentation or other architecture-independent parts as part of a general make/make install process, so it's not possible to create useful separate build-arch and build-indep targets. A lot of software has a doc dir and it is relatively simple to seperate recursing into doc from the rest. Unless the build-* targets become actually usefull nobody will put any work into splitting the build process into arch and indep parts though. Umm. Most of my packages I can simply call make or ake build and let upstream Makefiles build stuff -- which means that if the arch indep part is split of changed (./scripts dir, for example), I do not have to change my rules file to follow suit. In this case, splitting the buiild process into arch and indep parts is not trivial. I would think make will always do the customary all and include docs and such. But what stops you from having a make binary to compile and make doc in the Makefile? Yes you need to change the makefile and debian/rules but it usualy isn't that hard. Looking at the archive right now, there are only 129 source packages (in testing) that are not Architecture: all and declare Build-Depends-Indep (and quite a few of those are obviously wrong). So it seems to be a limited problem. However, if your concern is mostly to reduce installation time of documentation tools, then the current Build-Depends/Build-Depends-Indep setup seems to work quite well. I don't see where Build-Depends-Arch would fit in there. The problem currently is that it isn't even possible to seperate them even if the makefile suports it because the build target must be called. The proposal is as much a clarification and extension of the Build-Depends* fields as a mechanism to detect and use build-* targets. Only then can one split arch and indep building and have a meaningfull Build-Depends-Indep. I think the way to do this is to make the build target depend on build-arch and build-indep, so calling build builds everything, but allows for a future improvement in efficiency. Assuming, of course, that upstream build process also allows for this split up. We already have that like forever. This is not helping at all since you can't detect the existance of build-arch/indep in the makefile correctly and thus dpkg-buildpackage can never call it. So you always call build and always need all Build-Depends for arch and indep building. THAT is the core problem. manoj MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition
Manoj Srivastava [EMAIL PROTECTED] writes: On 16 Jun 2006, Goswin Brederlow stated: the current use and definition of Build-Depends/Conflicts[-Indep] in policy 7.6 don't match. Both use and definition also greatly reduce the usefullness of these fields. This issue has come up again and again over the last few years and nothing has been done about it. I hope this proposal provides a elegant and non disruptive way out so we can finaly do something about it. Currently policy reads: SNIP This comes down to Build-Depends have to be always installed. Buildds always and only install Build-Depends. Build-Depends-Indep, Build-Conflicts-Indep The Build-Depends-Indep and Build-Conflicts-Indep fields must be satisfied when any of the following targets is invoked: build, build-indep, binary and binary-indep. But buildds do call the build targets (via dpkg-buildpackage) and don't honor Build-Depends/Conflicts-Indep. And since build calls build-indep that means anything needed to build the architecture independent part needs to be included in Build-Depends. This make the Build-Depends-Indep quite useless. Proposal: - Two new fields are introduced: Build-Depends-Arch, Build-Conflicts-Arch The Build-Depends-Arch and Build-Conflicts-Arch fields must be satisfied when any of the following targets is invoked: build-arch, binary-arch. The existance of either of the two makes build-arch mandatory. The old fields change their meaning: Build-Depends, Build-Conflicts The Build-Depends and Build-Conflicts fields must be satisfied when any target is invoked. Does the converse hold as well? Is Build-Depends a superset of all dependencies until further notice? If not, if I am using an older dpkg-checkbuildeps or an older sbuild, my package may fail to build. That could be a requirement for a transitional period, like till etch becomes stable. Someone wanting to backport to sarge old-stable then would first have to backport dpkg/sbuild from stable (or copy the perl script manualy). Lets ammend the proposal with Until the stable release supports Build-Depends-Arch the Build-Depends field must be a superset of Build-Depends and Build-Depends-Arch and the same goes for Build-Conflicts. But I don't think this has to be spelled out in policy. Does this mean a package which conforms to the new proposal would fail if the an old sbuild/dpkg-checkbuilddeps is used? In other words, can someone running Sarge build a package from Etch? Yes it would fail and not it wouldn't build. But that depends on the above ammendment. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition
Wouter Verhelst [EMAIL PROTECTED] writes: Sbuild explicitely, by design, only looks at build-depends. So in order for build-depends to be useful at this time if you want a package to build, you need to list mostly everything in build-depends right now anyway. Isn't it sbuild's job to comply with policy, not the other way round? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition
Thomas Bushnell BSG [EMAIL PROTECTED] writes: Wouter Verhelst [EMAIL PROTECTED] writes: Sbuild explicitely, by design, only looks at build-depends. So in order for build-depends to be useful at this time if you want a package to build, you need to list mostly everything in build-depends right now anyway. Isn't it sbuild's job to comply with policy, not the other way round? Sort of. But policy is not usefull here and existing practice in some 8000+ source packages has a little more weight. The time to change sbuild to what policy says was some years ago. Now it is way to late. Now we have to fix just policy or policy and sbuild/dpkg-buildpackage in a way that doesn't break every source in debian. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition
Manoj Srivastava [EMAIL PROTECTED] writes: Previously, any new feature in dpkg which goes into release foo gets into policy in release foo + 1. Is there a compelling reason to diverge from this practice? manoj Isn't that for binary packages because otherwise you can't upgrade from old-stable to stable or from stable to testing/unstable anymore. If you mean gets used by gets into policy then I don't believe this was ever enforced for sources. For example udeb shlibs magic was added and is used in etch. Adding -gnu and new fields to dpkg-architecture output was added and is used in etch. And so on. If you mean that we agree on this now, implement it in dpkg and friends but only add it to policy after the etch release then that is fine by me too. But it doesn't feel right to just implement this in dpkg and then force this into policy later or decide that we don't want this at all. I don't think issues directly affecting policy should just be decided by the dpkg maintainers alone MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition
On Tue, Jun 20, 2006 at 10:50:46AM -0700, Thomas Bushnell BSG wrote: Wouter Verhelst [EMAIL PROTECTED] writes: Sbuild explicitely, by design, only looks at build-depends. So in order for build-depends to be useful at this time if you want a package to build, you need to list mostly everything in build-depends right now anyway. Isn't it sbuild's job to comply with policy, not the other way round? No. Policy is not a stick to beat people with. Our Policy document is not flawless, and errors have been known to occur in Policy before. While an inconsistency between Policy and an individual package is usually a bug in the package rather than a bug in Policy, the same is not true for highly influential implementations of whatever Policy happens to say; e.g., if the definition of the dpkg file format in policy differs from the actual implementation in dpkg, then we usually consider Policy to be either outdated or buggy, since in that particular case, stuff was written for Policy to document existing practice to people not familiar with the dpkg innards. The same is true for buildd/sbuild and build-dependencies; since build-dependencies were defined in Debian to make autobuilding possible, it would be madness to require that buildd and sbuild jump through every hoop that a high enough number of developers (i.e., 5) can come up with and get through the policy process. Therefore, if the implementation of sbuild differs from whatever Policy happens to claim, then Policy is simply wrong. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 signature.asc Description: Digital signature
Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition
Guillem Jover [EMAIL PROTECTED] writes: On Fri, 2006-06-16 at 23:10:36 +0200, Goswin Brederlow wrote: Package: debian-policy Severity: normal [Side note: Buildds/dpkg-buildpackage has no robust way of telling if the optional build-arch field exists and must call build. This is wastefull for both build dependencies and build time.] I've a counter-proposal. ;) Make dpkg source v2.0 (Wig And Pen) format require build-arch and build-indep. And when will that ever happen? - Build-Depends/Conflicts-Indep becomes usefull, build-indep becomes usefull Ditto. It won't have a usefull meaning for building just architecture all packages since that requires both Build-Depends/Conflicts and Build-Depends/Conflicts-Indep. There currently is no dpkg-buildpackage option for this but there are plans for it. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition
On 18 Jun 2006, Goswin von Brederlow outgrape: Peter Eisentraut [EMAIL PROTECTED] writes: Goswin von Brederlow wrote: On the other hand the savings can be huge. Think about how many packages install latex and fonts and generate the documentation needlessly during build. Installing and purging latex as well as all the initex runs and font generation takes up a awfull lot of time I think most packages build their documentation or other architecture-independent parts as part of a general make/make install process, so it's not possible to create useful separate build-arch and build-indep targets. A lot of software has a doc dir and it is relatively simple to seperate recursing into doc from the rest. Unless the build-* targets become actually usefull nobody will put any work into splitting the build process into arch and indep parts though. Umm. Most of my packages I can simply call make or ake build and let upstream Makefiles build stuff -- which means that if the arch indep part is split of changed (./scripts dir, for example), I do not have to change my rules file to follow suit. In this case, splitting the buiild process into arch and indep parts is not trivial. Looking at the archive right now, there are only 129 source packages (in testing) that are not Architecture: all and declare Build-Depends-Indep (and quite a few of those are obviously wrong). So it seems to be a limited problem. However, if your concern is mostly to reduce installation time of documentation tools, then the current Build-Depends/Build-Depends-Indep setup seems to work quite well. I don't see where Build-Depends-Arch would fit in there. The problem currently is that it isn't even possible to seperate them even if the makefile suports it because the build target must be called. The proposal is as much a clarification and extension of the Build-Depends* fields as a mechanism to detect and use build-* targets. Only then can one split arch and indep building and have a meaningfull Build-Depends-Indep. I think the way to do this is to make the build target depend on build-arch and build-indep, so calling build builds everything, but allows for a future improvement in efficiency. Assuming, of course, that upstream build process also allows for this split up. manoj -- Eat drink and be merry, for tomorrow we diet. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition
On 16 Jun 2006, Goswin Brederlow stated: the current use and definition of Build-Depends/Conflicts[-Indep] in policy 7.6 don't match. Both use and definition also greatly reduce the usefullness of these fields. This issue has come up again and again over the last few years and nothing has been done about it. I hope this proposal provides a elegant and non disruptive way out so we can finaly do something about it. Currently policy reads: SNIP This comes down to Build-Depends have to be always installed. Buildds always and only install Build-Depends. Build-Depends-Indep, Build-Conflicts-Indep The Build-Depends-Indep and Build-Conflicts-Indep fields must be satisfied when any of the following targets is invoked: build, build-indep, binary and binary-indep. But buildds do call the build targets (via dpkg-buildpackage) and don't honor Build-Depends/Conflicts-Indep. And since build calls build-indep that means anything needed to build the architecture independent part needs to be included in Build-Depends. This make the Build-Depends-Indep quite useless. Proposal: - Two new fields are introduced: Build-Depends-Arch, Build-Conflicts-Arch The Build-Depends-Arch and Build-Conflicts-Arch fields must be satisfied when any of the following targets is invoked: build-arch, binary-arch. The existance of either of the two makes build-arch mandatory. The old fields change their meaning: Build-Depends, Build-Conflicts The Build-Depends and Build-Conflicts fields must be satisfied when any target is invoked. Does the converse hold as well? Is Build-Depends a superset of all dependencies until further notice? If not, if I am using an older dpkg-checkbuildeps or an older sbuild, my package may fail to build. Build-Depends-Indep, Build-Conflicts-Indep The Build-Depends-Indep and Build-Conflicts-Indep fields must be satisfied when any of the following targets is invoked: build-indep, binary-indep. The existance of either of the two makes build-indep mandatory. The use of Build-Depends/Conflicts-Arch/Indep is optional but should be used in architecture all/any mixed packages. If any of them is omitted the respective Build-Depends/Conflicts field must be suffient already. ### End of Proposal ### - Simple to implement. + Trivial change in dpkg for the new field. + dpkg-checkbuilddeps has to parse 3 fields (2 with -B option) instead of 2 (1). + sbuild, same change + Simple change for 'apt-get build-dep' Does this mean a package which conforms to the new proposal would fail if the an old sbuild/dpkg-checkbuilddeps is used? In other words, can someone running Sarge build a package from Etch? manoj -- Linux: because a PC is a terrible thing to waste [EMAIL PROTECTED] put this on Tshirts in '93 Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition
On Mon, Jun 19, 2006 at 01:02:42PM -0500, Manoj Srivastava wrote: On 16 Jun 2006, Goswin Brederlow stated: The existance of either of the two makes build-arch mandatory. The old fields change their meaning: Build-Depends, Build-Conflicts The Build-Depends and Build-Conflicts fields must be satisfied when any target is invoked. Does the converse hold as well? Is Build-Depends a superset of all dependencies until further notice? If not, if I am using an older dpkg-checkbuildeps or an older sbuild, my package may fail to build. Sbuild explicitely, by design, only looks at build-depends. So in order for build-depends to be useful at this time if you want a package to build, you need to list mostly everything in build-depends right now anyway. It is in fact not against policy to list build dependencies that could technically be put in build-depends-indep in build-depends only, and I believe (though I'm not sure, and can't remember offhand where) that I have already seen some packages do so in the past. So, yes, for all practical matters build-depends right now is a superset of build-depends-indep. Build-Depends-Indep, Build-Conflicts-Indep The Build-Depends-Indep and Build-Conflicts-Indep fields must be satisfied when any of the following targets is invoked: build-indep, binary-indep. The existance of either of the two makes build-indep mandatory. The use of Build-Depends/Conflicts-Arch/Indep is optional but should be used in architecture all/any mixed packages. If any of them is omitted the respective Build-Depends/Conflicts field must be suffient already. ### End of Proposal ### - Simple to implement. + Trivial change in dpkg for the new field. + dpkg-checkbuilddeps has to parse 3 fields (2 with -B option) instead of 2 (1). + sbuild, same change + Simple change for 'apt-get build-dep' Does this mean a package which conforms to the new proposal would fail if the an old sbuild/dpkg-checkbuilddeps is used? In other words, can someone running Sarge build a package from Etch? old sbuild should not be an issue. Official buildd hosts never run sbuild from stable, they run sbuild from a separate repository at db.debian.org. If policy is updated to do something new which will benefit the buildd hosts, then sbuild will follow suit (provided there is code to do that) Of course, if a package does not build with old dpkg-buildpackage, that might be a problem; not sure about that. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition
Peter Eisentraut [EMAIL PROTECTED] writes: Goswin von Brederlow wrote: On the other hand the savings can be huge. Think about how many packages install latex and fonts and generate the documentation needlessly during build. Installing and purging latex as well as all the initex runs and font generation takes up a awfull lot of time I think most packages build their documentation or other architecture-independent parts as part of a general make/make install process, so it's not possible to create useful separate build-arch and build-indep targets. A lot of software has a doc dir and it is relatively simple to seperate recursing into doc from the rest. Unless the build-* targets become actually usefull nobody will put any work into splitting the build process into arch and indep parts though. Looking at the archive right now, there are only 129 source packages (in testing) that are not Architecture: all and declare Build-Depends-Indep (and quite a few of those are obviously wrong). So it seems to be a limited problem. However, if your concern is mostly to reduce installation time of documentation tools, then the current Build-Depends/Build-Depends-Indep setup seems to work quite well. I don't see where Build-Depends-Arch would fit in there. The problem currently is that it isn't even possible to seperate them even if the makefile suports it because the build target must be called. The proposal is as much a clarification and extension of the Build-Depends* fields as a mechanism to detect and use build-* targets. Only then can one split arch and indep building and have a meaningfull Build-Depends-Indep. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition
On Fri, 2006-06-16 at 23:10:36 +0200, Goswin Brederlow wrote: Package: debian-policy Severity: normal [Side note: Buildds/dpkg-buildpackage has no robust way of telling if the optional build-arch field exists and must call build. This is wastefull for both build dependencies and build time.] I've a counter-proposal. ;) Make dpkg source v2.0 (Wig And Pen) format require build-arch and build-indep. Why is this proposal better than others that have failed before? - non disruptive: Current buildd behaviour will continue to build all existing packages. Ditto. - Packages will not instantly have RC bugs. Ditto. - Simple to implement. + Trivial change in dpkg for the new field. + dpkg-checkbuilddeps has to parse 3 fields (2 with -B option) instead of 2 (1). + sbuild, same change + Simple change for 'apt-get build-dep' Those changes will not be needed. - Buildds/dpkg-buildpackage can use the build-arch target + reduces Build-Depends field and install time of same + build-indep is no longer called, reduces compile time and disk space Only will need changes in dpkg-buildpackage. - Build-Depends/Conflicts-Indep becomes usefull, build-indep becomes usefull Ditto. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition
Goswin von Brederlow wrote: On the other hand the savings can be huge. Think about how many packages install latex and fonts and generate the documentation needlessly during build. Installing and purging latex as well as all the initex runs and font generation takes up a awfull lot of time I think most packages build their documentation or other architecture-independent parts as part of a general make/make install process, so it's not possible to create useful separate build-arch and build-indep targets. Looking at the archive right now, there are only 129 source packages (in testing) that are not Architecture: all and declare Build-Depends-Indep (and quite a few of those are obviously wrong). So it seems to be a limited problem. However, if your concern is mostly to reduce installation time of documentation tools, then the current Build-Depends/Build-Depends-Indep setup seems to work quite well. I don't see where Build-Depends-Arch would fit in there. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition
Goswin Brederlow wrote: Two new fields are introduced: Build-Depends-Arch, Build-Conflicts-Arch You are aware, I hope, that the original proposal for the Build-* fields contained these fields, and they were dropped from the proposal after several people (buildd admins, if I recall correctly) indicated that they are useless in practice. I recommend reviewing the discussion and addressing their arguments in this proposal. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition
One question to ask is perhaps whether splitting the build dependencies into several sets is useful at all, considering that the current state of having effectively only one useful set has persistent for such a long time. Not a lot of people really understand the current definition, and this proposal introduces even more ways of getting things wrong. Not a lot of people practice local architecture-only rebuilds or some of the other corner cases that would be induced by this proposal. I'm afraid that this will just introduce more hard-to-detect bugs, and all the upload and rebuild time caused thereby will probably outweigh the download time saved by the buildds. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition
Peter Eisentraut [EMAIL PROTECTED] writes: One question to ask is perhaps whether splitting the build dependencies into several sets is useful at all, considering that the current state of having effectively only one useful set has persistent for such a long time. Not a lot of people really understand the current definition, and this proposal introduces even more ways of getting things wrong. Not a lot The current description is confusing and does not reflect actual use so people get it wrong. No wonder. of people practice local architecture-only rebuilds or some of the other corner cases that would be induced by this proposal. I'm afraid Every buildd does architecture-only builds so that will be well tested. The only other existing case is a full build which the uploader will test if he/she uses pbuilder or a chroot or such (and we all know everyone should do that). In the last 2 years more and more often someone has gone and rebuild the full archive from scratch, both with and without architecture indep packages given it even more testing. So what corner cases do you talk about? that this will just introduce more hard-to-detect bugs, and all the upload and rebuild time caused thereby will probably outweigh the download time saved by the buildds. A real bug in the Build-Depends (one missing completly) will be detected very quickly either by the buildd or by the next rebuild with arch-indep packages. A minor bug, such as having a package in Build-Depends instead of Build-Depends-Arch/indep, while being wastefull, is not harmfull. Same as having one in there that isn't needed at all. Sometimes people do notice and if not the waste can't be that big. I don't think that should worry us too much. As with Build-Depends[-Indep] detecting a useless dependency or one in the wrong place stays just as hard to detect as before and detecting a missing one just as simple so where should the extra bugs come from? On the other hand the savings can be huge. Think about how many packages install latex and fonts and generate the documentation needlessly during build. Installing and purging latex as well as all the initex runs and font generation takes up a awfull lot of time on say arm. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition
Package: debian-policy Severity: normal Hi, the current use and definition of Build-Depends/Conflicts[-Indep] in policy 7.6 don't match. Both use and definition also greatly reduce the usefullness of these fields. This issue has come up again and again over the last few years and nothing has been done about it. I hope this proposal provides a elegant and non disruptive way out so we can finaly do something about it. Currently policy reads: | 7.6 Relationships between source and binary packages - | Build-Depends, Build-Depends-Indep, Build-Conflicts, | Build-Conflicts-Indep | | Source packages that require certain binary packages to be installed | or absent at the time of building the package can declare | relationships to those binary packages. | | This is done using the Build-Depends, Build-Depends-Indep, | Build-Conflicts and Build-Conflicts-Indep control file fields. | |Build-dependencies on build-essential binary packages can be |omitted. Please see Package relationships, Section 4.2 for more |information. | |The dependencies and conflicts they define must be satisfied (as |defined earlier for binary packages) in order to invoke the targets in |debian/rules, as follows:[42] | |Build-Depends, Build-Conflicts | |The Build-Depends and Build-Conflicts fields must be satisfied |when any of the following targets is invoked: build, clean, |binary, binary-arch, build-arch, build-indep and binary-indep. This comes down to Build-Depends have to be always installed. Buildds always and only install Build-Depends. |Build-Depends-Indep, Build-Conflicts-Indep | |The Build-Depends-Indep and Build-Conflicts-Indep fields must be |satisfied when any of the following targets is invoked: build, |build-indep, binary and binary-indep. But buildds do call the build targets (via dpkg-buildpackage) and don't honor Build-Depends/Conflicts-Indep. And since build calls build-indep that means anything needed to build the architecture independent part needs to be included in Build-Depends. This make the Build-Depends-Indep quite useless. [Side note: Buildds/dpkg-buildpackage has no robust way of telling if the optional build-arch field exists and must call build. This is wastefull for both build dependencies and build time.] Proposal: - Two new fields are introduced: Build-Depends-Arch, Build-Conflicts-Arch The Build-Depends-Arch and Build-Conflicts-Arch fields must be satisfied when any of the following targets is invoked: build-arch, binary-arch. The existance of either of the two makes build-arch mandatory. The old fields change their meaning: Build-Depends, Build-Conflicts The Build-Depends and Build-Conflicts fields must be satisfied when any target is invoked. Build-Depends-Indep, Build-Conflicts-Indep The Build-Depends-Indep and Build-Conflicts-Indep fields must be satisfied when any of the following targets is invoked: build-indep, binary-indep. The existance of either of the two makes build-indep mandatory. The use of Build-Depends/Conflicts-Arch/Indep is optional but should be used in architecture all/any mixed packages. If any of them is omitted the respective Build-Depends/Conflicts field must be suffient already. ### End of Proposal ### Why is this proposal better than others that have failed before? - non disruptive: Current buildd behaviour will continue to build all existing packages. - Packages will not instantly have RC bugs. - Simple to implement. + Trivial change in dpkg for the new field. + dpkg-checkbuilddeps has to parse 3 fields (2 with -B option) instead of 2 (1). + sbuild, same change + Simple change for 'apt-get build-dep' - Buildds/dpkg-buildpackage can use the build-arch target + reduces Build-Depends field and install time of same + build-indep is no longer called, reduces compile time and disk space - Build-Depends/Conflicts-Indep becomes usefull, build-indep becomes usefull Large packages no longer have to build indep stuff in the binary-indep target to avoid building it on buildds. MfG Goswin -- System Information: Debian Release: 3.1 Architecture: amd64 (x86_64) Kernel: Linux 2.6.16-rc4-xen Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
