On Wed, Nov 2, 2011 at 11:10 AM, David A. Desrosiers < [email protected]> wrote:
> On Wed, Nov 2, 2011 at 9:25 AM, Phillip Moore <[email protected]> > wrote: > > efsdeploy, of the build system in general, is a much better place to > solve > > this problem You should see both of these patches in the next couple of > weeks, but the > > efs-core one's coming first. I have a short term need to get that audit > out > > of my way, due to how I'm building gnu/gcc now (separate discussion). > > So how does this work with this model, with users/developers who do > not use efsdeploy at all, to build or engineer their installs into > EFS? Java folks, binary vendor products, internally-build projects > using their own CI tools, etc.? > Remember: the ONLY thing we're able to audit are RPATH/RUNPATHs in ELF files. We have never been able to audit dependencies for Java, Perl, Python or any other type of install, and because efsd runs on a single platform, it will probably never be practical to audit both ELF and XCOFF simultaneously (the state of XCOFF-related tools, compared to ELF, is pathetic, but then... so is AIX, the reason I'm suffering XCOFF in the first place). Binary vendor products are totally irrelevant to this discussion. We don't hack their RPATHs (although.... we could in some cases), so that has never been an issue. For internally developed stuff, it's the build system they use, going forward, that will need this functionality (see below). > Does the dependency checking happen by efs-core calling efsdeploy, and > feeding that back into the core? Or some other method? > No, the dependency checking won't be done inside efs-core at all. It's moving to the build system, where it really belongs anyway. The audits in efs-core will be limited to the forbidden_files audit for now, which is one that is fundamentally NOT platform-specific. Platform-specific audits aren't feasible, and the we only got away with auditing ELF files because we only supported ELF platforms, and "readelf" allowed you do perform the audit in a platform-INdependent way. > In our world, efsdeploy is very minimally used, currently only < ~5% > of the products pushed out utilize it. With broader marketing, we may > get 20-30%, but we certainly won't get 80+% unless we enforce its use > for everyone (not likely). > First of all, efsdeploy is designed for installing pre-packaged open source products that we don't have any direct control over. It is NOT intended to replace systems like std-make, where we DO control the source, and it can be written and optimized for integration with EFS, which is one of the assumptions of stdmake. Having said that, I'm writing the script that does the sanity check in the verify step as a standalone script that can be run without using the entire efsdeploy framework. In fact, efsdeploy_strip_rpaths (which needs a rename, 'cause it's not just rpaths that it manages) can be used this way, too, so the developer of a system like stdmake could leverage it as well. The same will be true for efsdeploy_verify_library_depends (or whatever I end up calling it). However, the first pass will leverage the metadata.conf files generated by efsdeploy, so it might NOT be generically useful until someone actually, you know... wants to use it. Its a moot point until there's a real need, so 'm not going to prematurely optimize this by spending a lot of time coding for a possibly non-existent use case. > I just want to be sure we're not orphaning off dependency audits to a > tool that is not used broadly in the environment. I'm NOT ripping that code out, just deprecating it. You can still upgrade from EFS 2 to EFS 3, run this: efs define parameter install_audits_required dependencies,forbidden_files and get the current behavior. However, all future development efforts on improving dependency auditing will be done in efs-deploy, or it's related tools, NOT in efs-core. In that sense, the current code is being "orphaned" ( I prefer "deprecated") and that functionality being developed inside a framework where it scales. But having said that -- if someone else wants to put the effort into enhancing the efs-core dependency checking, have at it. What I'm saying is that I am no longer investing energy in that code, and it will be allowed to wither and die, 'cause I am personally not going to depend on it. I certainly won't stand in the way of someone else putting energy into improving it, as long as it's done well. For efs-core to perform platform-specific audits, it would need a means of running those audits natively on each of the various platforms, and ALL of that complexity and logic is in efs-deploy, NOT efs-core. I don't think it makes any sense to try to integrate the two, now or ever.
_______________________________________________ EFS-dev mailing list [email protected] http://mailman.openefs.org/mailman/listinfo/efs-dev
