Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orbit-dev] Modifying content of the last R-build

Hi Roland,

I am responding via orbit-dev list, just so its more open. Not that every harebrained idea has to be aired publicly but a) I usually do mine :)  and b) your ideas are good! Some minor comments inline.

On 01/06/2017 10:51 AM, Roland Grunberg wrote:
Hey David,

I hope the holidays have been good to you, and that you're having a great
new year :) 
Yes to both, thank you.
I'm looking into modifying content of the last R-build as part of
generating a newer one and would like to know any steps you may have
taken while doing this yourself in the past.
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.

Item #1 I'm not too worried about as I've tested and seems to work quite
well but I figured I'd mention it just in case. Item #2 has a few
approaches so I'm wondering how you did things in the past.


I'd like to :

(1) Modify the <properties> of every unit that is a bundle and contains
an id/version corresponding to some CQ.

I already have a script that does exactly this, and it's pretty much what
I do for the new (orbit-recipes) content. I've tested this locally and can
display all iplog information on one page.

There's a few outliers, particularly with some bundles lacking a listed
author but for the most part this works.
Sounds good -- a very sophisticated solution to associating CQ data with packages (IUs).

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.


(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.

I have not looked at the Java behind it and have always just use the ant task.  While this example script does not do what you are trying to do, perhaps p2RemoveIU.xml will get you started. Naturally, you either need to run from your workbench if you have a good connection to download and upload whole repositories or use Eclipse's "AntRunner application" if doing it in "batch mode".

It has the advantage of taking care of all the metadata data issues (as far as I know). And, you can do at several levels: specify only the id, and all versions (and pack.gz) files are removed, or specify the id and version an then that specific version (and its pack.gz file) are removed). Not all "queries" are supported, but explicit ids and versions are.

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_.

But that p2.remove.iu task is how I would approach it.


Looking forward to hear your thoughts.

Hope they help!


Back to the top