Re: [orbit-dev] Modifying content of the last R-build

[Roland Grunberg <rgrunber@xxxxxxxxxx>]

> Just to be explicit, I assume you mean to create an _additional_ "R-build"
> repository (without doing a build). I would be sure to leave the original
> "as is" ... just in case. The new one could have only the repository in it
> with a quickly hand edited DL page, and on it, beside pointing to the new
> repository, just mentioning it was based on the other one, but some IUs
> removed, and some properties added. Perhaps pointing to a bug number where
> the details would be.

Yes, an additional R-build based on the previous one with some units
potentially removed. The R-builds already released would not be touched. I
would consider archiving some of our much older R-builds as mentioned in
some past bugs.


> A minor point: We had the CQs in separate xml files partially so we could
> change the "status" of a CQ without doing a rebuild (Although, honestly,
> that was never surfaced on the webpage or implemented fully due to lack of
> time so not sure anyone would miss it.) :(
> See Bug 241243 and Bug 317531 if interested .

I've considered asking people to honour the "status" attribute in those
cases where a CQ qualifies for parallel ip, is approved for Orbit but is
still pending. However, we don't really display this information beyond
the xml ip_log file itself.

 
> (2) Remove units from the R-build
 
>> Assuming no one else is using them, or folks are committed to upgrading to
>> the latest version of some bundle, I can either do this through mirroring,
>> or manually.
>> 
>> The problem with mirroring is that although I can mirror everything but
>> the unit to be removed, this doesn't remove it from any feature groups
>> that would contain it, leaving them completely unsatisfiable if they were
>> to ever be selected for installation.
>> 
>> This would seem to leave only a manual approach of removing the unit from
>> the content/artifact repositories and from the metadata of any features
>> that included it. This isn't really "p2 API" but if one can see exactly
>> what mirroring would do, then that can easily be done manually on a
>> repository.
>> 
> Not sure what you mean by "manually", but there is a p2 API (sort of -- at
> least an Ant task) that would help and that is how I modify repositories
> "after the fact": See p2.remove.iu in Eclipse Help.

By "manually" I meant with a text editor. The format is pretty straightforward.
I recall doing a diff between 2 repositories where one was mirrored with a few
units being excluded and it was basically just removing <unit>/<artifact> tags
and decrementing the size attributes.

With that said, I'll definitely give the p2.remove.iu task a try. I may have
unfairly skipped over it when I noticed it was only supported as an ant task.

> As far as features or feature groups: I thought we removed the "features"
> from the repository anyway, since a) that are not installable without
> conflicts and b) it is a very bad idea to do that so we wanted to protect
> "casual users". I do not recall exactly, but my point is if the "feature
> jars" are not already removed, I _think_ you can probably remove them too.
> (But, not sure. And, you probably can not remove the "feature.groups", since
> that would remove all its bundles too, I _think_.

Yes 'org.eclipse.orbit.build.feature.set1.feature.group' would fail because
'org.eclipse.orbit.build.feature.set1.feature.jar' is nowhere to be found.
I guess installation of the feature.groups may fail if the requirements don't
get properly updated but they can still be mirrored which is ultimately what
we care about.

Anyways, this has definitely given me some better insight into how to do this
and some things to try as well. Thanks again.

Cheers,
-- 
Roland Grunberg