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
