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?
> 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 lifl-dev is Multi-Arch: same?
>> So the most correct fix is to correct the dependencies to say which is
>> wanted everywhere? But as you observe, that's a big job, even the dim,
>> automated, version which just puts in both, as above.
>
> It depends on what "Depends: flex" is supposed to mean. Given the above,
> I see the following major options:
> 1) A flex executable, that can generate C sources, which can be built
> for the host architecture. If you work with C++, you need to add
> libfl-dev to Build-Depends.
This seems to actually reflect what I see as reality. Most
lexers are still C lexers in my unscientific survey.
> 2) A flex executable, that can generate C/C++ sources, which can be
> built for the host architecture.
>
> 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.
> The latter case is just my patch.
> If you ever happen to need flex for both the build and the host
> architecture with C++ libraries, the Build-Depends will become "flex,
> libfl-dev, libfl-dev:native" for 1 and "flex, flex:native" for 2.
> 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.
> 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.
manoj
--
What foods these morsels be!
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C
Attachment:
smime.p7s
Description: S/MIME cryptographic signature