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 system. From: Krzysztof Daniel <[email protected]> To: [email protected], Date: 09/16/2013 01:29 PM Subject: Re: [p2-dev] Security/maintenance updates for Eclipse & RPMs Sent by: [email protected] Hey David, 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 Fedora. 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... -- Krzysztof Daniel <[email protected]> Red Hat _______________________________________________ p2-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________ p2-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/p2-dev
