> On Apr 21, 2015, at 19:31, Daniel Macks <dma...@netspace.org> wrote:
>
> On Tue, 21 Apr 2015 14:14:10 -0500, Hanspeter Niederstrasser
> <f...@snaggledworks.com <mailto:f...@snaggledworks.com>> 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
> dma...@netspace.org <mailto:dma...@netspace.org>
>
>
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.
--
Alexander Hansen, Ph.D.
Fink User Liaison
------------------------------------------------------------------------------
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
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
