I'm not sure what you mean by "doesn't
scale". In a to-not-be-named project I used to work on we'd
do dozens of patches, sometimes with dozens of bundles in (nearly) each
... sometimes just a month or two apart. Of course, that was all automated
with PDE build ... not sure how Tycho/Maven handle these.
Sounds like it is the bottle neck for
you is "detecting when something has changed"? (And therefore
has to be re-done as a feature patch?)
I don't understand your system, obviously,
(even less about rpms) but (at least with PDE Build) it was pretty easy
to automate the building of (only) feature patches.
Just trying to be helpful ... and understand
what you mean ... not arguing if they are or are not scalable for your
Krzysztof Daniel <kdaniel@xxxxxxxxxx>
09/16/2013 01:29 PM
Security/maintenance updates for Eclipse & RPMs
Software managed by RPM is distinguished by it's location, so there is
no risk of replacing a wrong bundle. Feature patches are great, but they
don't scale :-( - in the sense that I can't monitor all Eclipse features
for all dependencies - and ship feature patches in-sync. Not to mention
that each new feature patch would require package rebuild. As I've said
- feature patch does not scale for such a fast changing environments as
That's why I still hope I will be able to patch out features
on-the-fly, when a new version of a library is detected. The only
question is whether a patched feature will satisfy all the requirements
it was satisfying earlier.
But maybe there is another approach I did not think of...