On Tue, 28 Apr 2015 07:52:03 -0700, Alexander Hansen <alexanderk.han...@gmail.com> wrote:
> > 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> 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 > > 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 dma...@netspace.org ------------------------------------------------------------------------------ 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
