On 22.03.2011 12:54, Mark Hymers wrote: > On Mon, 14, Mar, 2011 at 02:04:30PM +0000, Hector Oron spoke thus.. >> Hi, >> >> 2009/11/2 Mark Hymers <m...@debian.org>: >>> On Mon, 02, Nov, 2009 at 12:43:42PM +0000, Philipp Kern spoke thus.. >>>> Of course it is a sane approach but very special care needs to be taken >>>> when >>>> releasing to ensure GPL compliance. So what we should get is support in >>>> the >>>> toolchain to declare against what source package the upload was built to >>>> keep that around. > > Ok, I'm only going to comment on this part. This is nearly implemented > and should be there by the end of the day (I need to run up some test > packages to work with). > > The current design is the Binary packages can contain an additional > control field: Built-Using. > > The specification of this field is that it *must* contain only strict > version dependencies and these must be to source packages. I.e. > > Built-Using: gcc-4.5 (= 4.5.2-5) > > If dak can't parse this field, or the source versions which are declared > are not present when the binary package is uploaded, it will reject the > upload. If it can parse and find these dependencies, it stores them in > an extra table in projectb which prevents us from throwing away the > relevant source files until these binaries no longer exist anywhere in > the archive, the same way as we handle it for the normal source case. > > I'm not entirely sure where this should be documented, it's not really a > policy thing as it's specific to the archive. Suggestions welcome. > We'll obviously include it in the minutes to d-d-a at the end of the > meeting (the main people this should be used by, as far as I know are > cross-compiler builders and the d-i and kernel-wedge people).
that would be too strict for e.g. gcj-4.5 Built-Using: gcc-4.5 (>= 4.5.2-1~), gcc-4.5 (<< 4.5.3) would be correct, however this already can be expressed in the build dependencies, so I assume packages like gcj-4.x, gdc-4.x, gnat-4.x don't need to be changed. Matthias _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
