Re: Handling flat_namespace on 10.10+

On Tue, 28 Apr 2015 07:52:03 -0700, Alexander Hansen 
<[email protected]> wrote:

>
> On Apr 21, 2015, at 19:31, Daniel Macks <[email protected]> wrote:
>
> On Tue, 21 Apr 2015 14:14:10 -0500, Hanspeter Niederstrasser 
> <[email protected]> wrote:
>
> On Thu, April 16, 2015 11:46 am, Alexander Hansen wrote:
>
> Summary: GNU libtool effectively assumed that there would be no 10.10, so
> a bunch of packages inherited conditional logic that treats 10.10 like
> 10.1. We’ve been patching against this, and put a .deb validator check
> for flat_namespace builds. 
>
> Problem: openmpi apparently requires flat_namespace. Other packages
> might also need it, too, but I don’t happen to know of any offhand. 
>
> There are a couple of options to address the problem:
>
> 1) Add a boolean override field, e.g. BuildFlatNamespace, to the .info
> and have that turn off the .deb validation check. 
>
> This seems like a gateway to propagating new fields with very limited
> usage. The last couple of new fields (RuntimeDepends, NoBuildAsNobody,
> etc) had a significantly wider need. So far BuildFlatNamespace has N=1. 
> Would it make more sense to have a new more general field that can receive
> a comma separated list of pre-set values, and each value would indicate a
> action?
>
> RandomTidbitField: AllowFlatNamespace, ThwackUserWithTuna
>
> Could Type: be extended in this manner?
>
> 2) Get rid of the .deb validation check and instead apply mandatory tests
> in the earlier phases. For example, to test at the end of the compile
> phase fink-package-precedence could be extended also to check for
> flat_namespace and packages which need flat_namespace wouldn’t use
> f-p-p; or an additional option flag could be added to f-p-p. We could
> also check config.status before the compile phase. 
>
> Would built debs still be validatable (by hand)?
>
> If it controls a validator test, it needs to be in the .deb control 
> file, which means we have to tweak dpkg itself to accept a new foreign 
> field. All for an apparently *very* rare special case? No thanks. 
>
> Support via f-p-p or a new "fink-library-check" (either one controlled 
> by comand-line flags in the CompileScript) or internal to fink itself 
> prior to rolling the .deb (controllable by some .info field) would make 
> it happen in fink runtime and not require .deb/dpkg hackery. As a 
> bonus, it keeps the buggy-library from ever making it into a .deb for 
> anyone rather than lurking and spreading until someone uses -m to catch 
> it. 
>
> We already have support for a special token in Shlibs entries to 
> control certain binary library features (32/64-bit cross-arch), so a 
> new "Flat" token could be added there. I think it's a per-file idea, 
> not per-package? I dislike doing it via grep of config.status...we want 
> to catch bad results regardless of how they came about, not just the 
> one way we currently see. Likewise, fink-library-check would take a 
> list of specific file(s) to allow to be flat, not just enable/disable 
> the whole mode (and would allow scanning .so not just .dylib). There 
> are some other sanity checks we might want to do on modules and libs 
> (unresolved symbols? list of runtime deps?), this new script would be a 
> home for them all. 
>
> dan
>
> --
> Daniel Macks
> [email protected]
>
> Yeah, I’d definitely prefer not to have problematic .debs actually get built. 
>
> However, since we kind of need to get a release out shortly, and we 
> currently don’t have code in Fink to handle this, I’d like to 
> know whether to turn off the current flat_namespace check in the 
> validator so that openmpi can get added to the binary distribution or 
> just leave it as-is. 

Knock it down to a non-fatal (remove $looks_good=0)? That way it can be 
caught by buildworld and maintainers who look closely, but won't 
prohibit. 

dan

--
Daniel Macks
[email protected]


------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Fink-devel mailing list
[email protected]
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel