Re: [Fink-devel] Handling flat_namespace on 10.10+
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)? Hanspeter -- More agile than a turtle, stronger than a mouse, nobler than a lettuce -- 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_15utm_medium=emailutm_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
Re: [Fink-devel] Handling flat_namespace on 10.10+
What about a fink flag that would allow certain stages of validation to be skipped. Something like --disable-validation= where it could be passed the major stages like deb, etc. On Tue, Apr 21, 2015 at 3:14 PM, 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)? Hanspeter -- More agile than a turtle, stronger than a mouse, nobler than a lettuce -- 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_15utm_medium=emailutm_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 -- 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_15utm_medium=emailutm_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
Re: [Fink-devel] Handling flat_namespace on 10.10+
On Apr 21, 2015, at 12:24, Jack Howarth howarth.at.f...@gmail.com wrote: What about a fink flag that would allow certain stages of validation to be skipped. Something like --disable-validation= where it could be passed the major stages like deb, etc. That functionality already exists, sort of. -m mode is “fink --validate=on --tests=on” with some extra fatality thrown in. Switching to --validate=warn will pop up messages but not cause the build to error out. Though that also loses some of the other changes from warnings to fatal errors. From a maintainer standpoint this may be sufficient. The problem, of course, being that auto builder scripts _should_ use -m. And adding a flag to fink wouldn’t really help with that because it negates the “auto” part. On Tue, Apr 21, 2015 at 3:14 PM, 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? There’s probably room for additional magic in Type, yeah. We’ve got some other packages in the distribution that go through hoops to appease the validator, so maybe some general override options are in order. 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)? Hanspeter -- More agile than a turtle, stronger than a mouse, nobler than a lettuce Sorry, my wording there was a bit broader than I intended. :-) What I meant is that the .deb validator wouldn’t run the check for flat_namespace any more. Instead, we could have packages run a script at the end of the configure phase to grep for flat_namespace in e.g. config.status, run another script to check the libraries, etc., and give fatal errors if problems are detected. Ideally, it’d be nice to retain the .deb test, since that lets maintainers know that their package needs to be updated and reduces the chance of users having misbuilt packages. -- Alexander Hansen, Ph.D. Fink User Liaison -- 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_15utm_medium=emailutm_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
Re: [Fink-devel] Handling flat_namespace on 10.10+
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_15utm_medium=emailutm_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
