[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: flex is no longer M-A:foreign



On Sun, Feb 07, 2016 at 08:43:25PM +0000, Wookey wrote:
> +++ Helmut Grohne [2016-02-07 18:25 +0100]:
> 
> cc: Manoj as I guess he's not on this list, and seems amenable to
> discussion on the best way forward.

Sorry for the obvious omission and thanks for adding the Cc.

> 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). 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.

> 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.
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.

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.)

> It does seem to me that the issue here is that things which want
> flex-dev:$host don't explicitly say so, and instead we have flex
> depending on flex-dev itself, which was an interim thing that we
> should drop and correct the deps/build-deps. Does flex in fact always
> need flex-dev (for build-arch?) I have forgotten how flex works but
> veguely recall from the vintage of #611230 that it is somehow special.

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.

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.

In any case, I'd appreciate a timely solution as quite a number of
pseudo build-essential packages are affected (dpkg, gcc-N, hurd,
libsepol, man-db, pam, ...).

Helmut


Reply to: