The quest for a solution continues... After looking at how I did this in mdl, I realized that in practice, there are VERY few perl5 releases where the metadata.conf file will vary from platform to platform. Therefore, I went ahead and simplified the script to generate the "cache" metadata.conf files in a common install ONLY.
Basically, I use the contents of the first platform-specific install to generate the file, and then I'm done with the release. if we encounter any strange releases for which this optimization doesn't work, we'll just rebuild them with efsdeploy, and then they will have their own, properly generated metadata.conf files, and the cache won't be used. If you look in /efs/dist/perl5/metadata/current/common, you'll see how these data files have been constructed. I have not yet committed the patch to EPD that looks here, but will tomorrow (or today, maybe). Unless we build any more perl5 modules using perl5/config, this problem is solved. Everything build with efsdeploy will have it's own metadata.conf files, and with this cache, we get FULL coverage of the entire perl5 metaproj. We can always rebuild the cache again, if needed. On Sat, Aug 7, 2010 at 12:21 PM, Phillip Moore <[email protected]>wrote: > > Yeah, I know, I shouldn't be working on a Saturday, but I can't get this > puzzle out of my head. Just don't read all this crap until Monday :-P > > OK, after further analysis (and a revalation that occurred to me while > walking the dogs...) this CAN be done with a single perl5/metadata release. > The key is to learn from mdl, and simply "fill in" the missing parts of the > namespace in the newer installs, with (what else) symlinks back to the older > ones. > > I've got a design for another version of efsdeploy_metadata_cache that will > accomplish this, and I'm pretty sure I'mm have it written over the weekend. > My head will NOT stop spinning on this until it's done. > > I am ready to predict that Jerry and I will have EFS::Perl::Depends working > in the legacy environment, with efsdeploy, by the end of the month.... > > On Sat, Aug 7, 2010 at 11:20 AM, Phillip Moore > <[email protected]>wrote: > >> >> Actually, these metadata releases ARE needed in prod, since they are >> accessed at runtime. That is a much stronger argument for NOT using a >> single uber-release to manage this data. >> >> The more I think about this, the more it's clear we need these "shadow" >> metadata releases.... >> >> On Sat, Aug 7, 2010 at 11:02 AM, Phillip Moore <[email protected] >> > wrote: >> >>> I couldn't leave this alone and hacked up a script to generate the >>> retroactive metadata for existing releases. >>> >>> However, the experiment failed, for a very subtle reason. The idea was >>> to create a single release with all the old metadata in it. That won't work >>> because the releases have varying platforms, and if you create a >>> sparc64.sunos.5.10 install for the few releases that need it, then there >>> won't be any metadata in that install for the releases that were NOT built >>> natively on that platform. >>> >>> Look at the contents of /efs/dev/perl5/metadata/next/install to see what >>> I mean. It won't be obvious, and if you care, ask and I'll explain. >>> >>> Instead, we need to create metadata *releases*, side by side with the >>> real releases. For example, if we have a legacy release with no metadata, >>> like perl5/Foo/1.0-ml01, then we will need to create >>> perl5/Foo/1.0-ml01-metadata, AND we'll have to create the SAME set of >>> releaselinks that point the underlying release with similar names. If >>> there's a perl5/Foo/1.0, then we'll have to create a perl5/Foo/1.0-metadata. >>> >>> This will allow us to create these metadata releases with the SAME set of >>> platforms as the underlying release, and generate the missing metadata.conf >>> files for them. >>> >>> The code to do so will also have to distribute these "shadow" metadata >>> releases, but only if the underlying release has been disted. Strictly >>> speaking, these are ONLY needed for building things, so they never become >>> prod, and we really only need them in d.lvt anyway. >>> >>> This is, I admit, kinda ugly. I have one other possible trick that >>> MIGHT work with the perl5/metadata concept, similar to how the "mdl" script >>> handles creating symlink tree to releases that have varying platforms, but >>> I'm not sure if that will work. I know the above will. >>> >>> I'll follow up again when I've worked through more of this problem... >>> >> >> >
_______________________________________________ EFS-dev mailing list [email protected] http://mailman.openefs.org/mailman/listinfo/efs-dev
