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
