+++ Manoj Srivastava [2016-02-08 00:58 -0800]: > On Sun, Feb 07 2016, Helmut Grohne wrote: > > > On Sun, Feb 07, 2016 at 08:43:25PM +0000, Wookey wrote: > >> +++ Helmut Grohne [2016-02-07 18:25 +0100]: > > >> Presumably in fact some packages want libfl-dev (:$host) and some want > >> flex (:native)? It's just that for a very long time there was only > >> 'flex' which had both so deps/build-deps do not distinguish. > > > As far as I can see, one always wants the build architecture flex > > binary (i.e. :native). > > So it should really be OK to label flex itself Multi-Arch: > foreign, as long as it does not haul in libfl-dev? Correct. > > Furthermore it seems that libfl-dev is only needed when you do C++ > > builds (the #include <FlexLexer.h> is only generated then). I have not > > yet encountered packages that need libfl-dev for the build > > architecture. pam needs libfl-dev for the host architecture. > > And then libfl-dev is Multi-Arch: same? Correct. > > In the former case, flex should stop depending on libfl-dev, because it > > is no longer part of the public interface and some packages (like pam) > > need to add that dependency explicitly. Then flex can become M-A:foreign > > again. > I like this. And it is conceptually the simplest for package-maintainers to use. (Depend on flex, depend on libfl-dev if you use c++, arches will 'just work' with no mysterious :native for unobvious reasons) > > Either way, it looks like someone should do a partial archive rebuild > > (500 build-rdeps of flex) with the flex -> libfl-dev dependency dropped > > to see what it would mean. Unless someone is faster than me, I'll look > > into that. (In particular, before doing a MBF.) > > I would like to help with that, though at work we are doing a > disaster recovery week, so my time might be limited until next week. > > > If I am reading the bug correctly, libfl-dev is an implementation > > detail as a result from a package split. It was split due to Riku > > Voipo recognizing that libfl.a would be needed for a different > > architecture than /usr/bin/flex. What did not happen though was > > packages adding a libfl-dev Build-Depends, so for all practical > > purposes, libfl-dev remains part of the interface of flex now. > > That is technical debt that we perhaps should fix? This is a > non-release year, if I read the tea leaves right, and we have time to > do this right. That means a freeze twards the end of this year, so not as long as one might like, but it's do-able so long as we apply some effort and a probably fairly ruthless with the NMUs. > > So in summary, I still prefer my patch, because > > 1) We don't have to touch many source packages. > > 2) We don't have to distinguish between C and C++ packages. > > 3) Build-Depends stay shorter and more intuitive. > > 4) We don't have to test build 500 packages. > > I think the right thing is to not pull in libfl-dev when it is > not needed; and yes, that does mean detecting and fixing the build > dependencies of packages that break in the archive rebuild. > > As for timeliness, I think I can fairly quickly upload a flex > that does not pull in libfl-dev into experimental, and we can go ahead > and see what breaks, and come back and revisit this. OK, I'm not going to argue if you prefer to do it that way. So long as we don't let it moulder too long it should be OK. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
Attachment:
signature.asc
Description: Digital signature