Community
Participate
Working Groups
As part of the shared install work, we're currently thinking about spoofing a profile from the running bundles.txt and maybe metadata denoting root IUs.
I'm having some issues with the change from IProfile to Profile in SimpleProfileRegistry; specifically saveProfile. I'm probably just having a braindead moment or two here, but any suggestions would be greatly appreciated. I'll submit a WIP patch (with one compile error).
Created attachment 90425 [details] work in progress patch Note that there's also the sharedprofile project in CVS.
Created attachment 90426 [details] updated patch
Created attachment 90440 [details] my take
Thanks, Simon. I'm now at the point that I have a single IU with RequiredCapabilities on all IUs in the shared repo (passed via a property) with IInstallableUnit.NAMESPACE_IU_KIND="group". Is there a better flag or something I should be using? I run into a problem when attempting to install this IU. Since the profile doesn't really exist, its install folder is null and therefore when the engine attempts to install, Util.getInstallFolder returns null and the transaction fails. I would greatly appreciate any suggestions on how to fix.
Created attachment 90871 [details] Latest (2008-02-27) patch including Simon's fixes
Andrew, see bug #215560. To mark IU's as locked in your spoofed profile, you'll want to use something like: mySpoofedProfile.setInstallableUnitProfileProperty(iu, IInstallableUnit.PROP_PROFILE_LOCKED_IU, Integer.toString(IInstallableUnit.LOCK_UNINSTALL | IInstallableUnit.LOCK_UPDATE)); The engine and planner don't look at these properties, but the automatic updater and UI do.
(In reply to comment #7) > Andrew, see bug #215560. > To mark IU's as locked in your spoofed profile, you'll want to use something > like: > > mySpoofedProfile.setInstallableUnitProfileProperty(iu, > IInstallableUnit.PROP_PROFILE_LOCKED_IU, > Integer.toString(IInstallableUnit.LOCK_UNINSTALL | > IInstallableUnit.LOCK_UPDATE)); > > The engine and planner don't look at these properties, but the automatic > updater and UI do. Thanks, Susan!
Marking for RC1. We have profile surrogate creation code now in the current build but need to at least conside locking the root IUs from the base.
For the locks we would use LOCK_UNINSTALL and LOCK_UPDATE from bug 215560. This would just be a lock at the UI level and is ignored for direct changes so would still allow us to update the base directly using the planner.
Created attachment 98414 [details] patch
Looks good.
Fixed in HEAD