Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] RPM-P2 integration - new approach
  • From: Krzysztof Daniel <kdaniel@xxxxxxxxxx>
  • Date: Fri, 25 Oct 2013 14:12:40 +0200
  • Delivered-to: p2-dev@xxxxxxxxxxx
  • Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAHIklEQVRYw61YTWwbxxX+SC5FmVr9mCuzNF1KlFFT5GphG1VaJYHSGE4QA+LNhwrJQb32XLg5BT4YaBAkhdGjz0JTQD4YuYiHIjHk2khqIKnlYLUUKcCmvYFD0FqHspcEKS61PbzlcMU/kyIHxGJ3uDvzzffe+96bcVRKBnppVaPq4lx07eadhit7p93nzl7RNA9XNapGSTNKWsO/9nfsPR1WAoDrBgEbwj6WUdIeZ4prqze21ldZ51x8ZXnlz6d/E2z5STfN0cFk7RiuGtWHX9784vrHHcb9618+P7v8ATcstBytA9C2gJiXNLjLzrbawEq7RmydiYbsTDdQ3htDzW1nW726/HZPJri29u2ZaKjd8vpyaqOkra3eQI/t6vLbO9sqcUP0sJu+AFWN6mfXrnew1McfLdmNxa4A1lZvGCWty4m410oO3T/88mZLNHPxlfj4LsO0vjdJrzE0ALbWV3+clX77pw87ENMVIIamalQTKdkOYmt9tQZld31vkmGKj+/GP1oCrEfEVwhfIiWfa9LGozu13ZftlHTTGGf//Oo/rpmZltLasw+9un/P7hzre5PdA2LoH5W5fn2og7sAiIUiSTXd/FosFGnyd3z+r8Sr+/cQ/XAwgBIpeS6+ckXyQfgDAGgyAMyLsXkRPygAkmo6dv4ywgetv1fTRG2/Tm2X/Pj4roUGwLzIewPW/TsBAL/DxeYP9WLWxll6PSWfwx9fO11v2R7hg7Y0NLU66MPO1C+gQ+GQceIITZAAmIELA3Pq+uJs9JgeoVFCyhp1Osqa3WTQ5FgoolQwGIaaF9dgi3YQ2702UB/qpsIqay1NBgDq08EAEgO+7kGYHoF+dZLCBwAc2Y3Kd7dMI9+XD1WNauXmP5RKUAxFaNyWhrAbqzw2Qjeel4eAkmB6XhbKY3Bw! E0cEZBp5C JKoyUolKNbUhWGiuT0vC/Z7eiw8SBo1/QSgVILimxMsSE0jD044CiBaCv/ORdzeRsapZF84shvWis9f5kU/cUNohp8/1YtZ5b/5REqOj+9aOeQHhTCRpu8XIhjrw2QuzlUBdCVXyxjB2PnLSvYFgOTmLWxasIafawB0JZfc/MoBLM1eiAV8CB/w3gBBFAM+aM+SavrsW30XaLzo1+/eFgPS3+/IVyQAPkd2Y31vEpiMj+9Ck/ViPZPEQhGlEkyk5EQK8c0aSQgifICwGBtI2JeNCYqU+PhuUk0nN2+ZgQtLs5b4JtU02YIopPwfH9+9Ivko6UKQRhcWLZUXpKERV78Fmiv3tPAgCUDJvhADPmiypSuanFTTRInVz9q8yHsDZGjys8IvW4SJe/cNyzTDwhFTx77vFMJbAET4eNGvF0Xe6wegKxIzAS/6gYv63dsMjekReLFRpXjRXxpIcuW9Ad4baKFDggRAdD9r4IaBYApJAd+c/o6o1KUTU3b5OZQ47ZlhXmzQayaSFHH1xyNEmX3Pyw0LnuNz+i9bhMn0CDwAkWBJDQmVKROJpKOs0WJKJ6YGkFxpl1k1qvu+U+6haIsSzO7LGaeu5FokVxaqVkqx1HwQBVq7fM6qJU0mTC2n7IDjKOVHs4ToSg6CxIv+0okp0yOQIPGiv9235EPlsZEOzvR6QORMppHfL7TaM2iyruSGnz+1lKbm18Qi43K/UGX0dDZZp/MhwvE4Uww9USh//f5i9FCU2Uvs9sWJruTUafG0x6jsb7uHosRW1T/VW5QRFNqzKgDJf9kwPFy+RcFfq7UPyUENX3Lzlpl98Whh8bQnWkmnK4A7EnH1GvY/rv2bakV1uq4uj8pcjDtkLxIhmlgvZpFxWp3hA9ZJFf5M2GsCbkQAVNJp18xMz6ljdGFRtW3vayRNeLg87w3oyNHqY6GIfvdQBc2LfqLKIkyQxFp1ZZ4EarB6AzS6sMjOGET3s2Q2D! SzS4ipkoD DqFYUgNTsToeG9AT2cdQ9FTcA08sad793vvY/QRM9RFvrfTUd2w5HdoFTFdkJ1C2acVFFYtiOFrBVlDE1tuCkHN+H4+SWAyjdfdyj12zKkVIIIBAFA8KnT4igwE/Y+zhSZt5LJqPKqdfrr/9pyH0m8i3OV0tZpiXHne+7Spd4YIo8ZXVhklBCambDXVnJY0zdEO6Fhud08OUY6wr37hvu99weg1K/u33t1/x4dwT7OFFVTslKs6EfGaQ91ZixCQznfwU1Q/qGb4UuX3JHenZpOx+1nl4Ts7PIHAPQn2RGqdcJUwzsBp44c4ET4YOT4HNsV7ftOscN/ovxMNNQu5gG4rn5ytfVhyk+5Pd/JxsNGLXdq+tzxCfeT/PFjpa2hY/6hY/5fT43sPy9AkyFO8sFfufnpBjR0iJtIyTtabrpU+vmhfCIadHLennVoaVYaXVicCXvZRpPkG5aDS6EHCnkSlbD2mpDQkKV2tlU2YCIlL81Kn127/smnf2s56f8BT1i2ky/8xFYAAAAASUVORK5CYII=
  • List-archive: <https://dev.eclipse.org/mailman/private/p2-dev>
  • List-help: <mailto:p2-dev-request@eclipse.org?subject=help>
  • List-subscribe: <https://dev.eclipse.org/mailman/listinfo/p2-dev>, <mailto:p2-dev-request@eclipse.org?subject=subscribe>
  • List-unsubscribe: <https://dev.eclipse.org/mailman/options/p2-dev>, <mailto:p2-dev-request@eclipse.org?subject=unsubscribe>
  • Organization: Red Hat

Hey Pascal,

you're previous message was in some places incomplete - especially
interesting to me was the part that would go after "If precision was
something necessary, then we could have a storage of ".

the problem that I've found in the past[1] is that it is impossible to
generate fully working configuration just from the bundles itself,
specifically bundles start levels are unknown. 

I believe that for this reason it is necessary to ship either repository
metadata, either fragmentary bundles.info (or ship start level info in
any other way, but those two seems to be the simplest one). Hence the
idea of generating the fragmentary bundles.info during the build (via
tycho/maven plugin). As a bonus, we avoid filesystem walkthrough. 

I'm not sure whether this approach to bundles.info belongs more to
droplets, or to the dynamic profile generation. It looks like something
in between. The assumption is that master Eclipse will be entirely
managed by RPM. As I don't expect anything but the installer to write to
the bundles.info in the master configuration, I think there is no need
to change any other simpleconfigurator logic than mentioned above. I
could implement saveguards to ensure that this path will not be merged
until simpleconfigurator is configured with a read-only directory.

The change that is required in the simpleconfigurator could be similar
to [2] (pretty-old code). 

As of profiles - I initially thought of generating also a fragmentary
profile, that would be merged together on the same basis as
bundles.info. The idea was to generate it during build time, and then
merge when it would be necessary to access it.

On the other hand, shipping profile-less Eclipse just with bundles.info
would definitely allow for spoofing the entire profile on-demand. If we
have bundles.info (but the proper one, with start-levels), we can easily
regenerate the shared profile when necessary.

After reading all that what I've written it looks like it is very close
to the 'dynamic profile creation' scenario, with a couple of minor
differences.

[1]
http://eclipseandlinux.blogspot.com/2012/02/making-p2-working-with-rpm-milestone-i.html
[2] http://fpaste.org/49439/82700200/

-- 
Krzysztof Daniel <kdaniel@xxxxxxxxxx>
Red Hat



Back to the top