Are the checks for the shlibs in Validation.pm done for the files from all packages at once or as sets for each package and/or its split-offs? If the latter, what about the idea of hard-coding a blacklist into Validation.pm of packages and/or split-off which should be skipped?
On Tue, Apr 28, 2015 at 11:00 AM, Daniel Macks <dma...@netspace.org> wrote: > > > 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 ------------------------------------------------------------------------------ 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
