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
