On Tue, 21 Apr 2015 14:14:10 -0500, Hanspeter Niederstrasser <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 ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ 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
