[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [p2-dev] Provisioning p2 with p2?
|
Hi,
Thanks for the elaboration, after plowing through the code of the
installer I came to that conclusion as well, I guess the installer and
agent are off limits then.
Thanks again,
Fredrik.
On Wed, Mar 11, 2009 at 15:18, Pascal Rapicault
<Pascal_Rapicault@xxxxxxxxxx> wrote:
> The installer is not written to do what you are after nor is it completely
> correct in what it does today.
> Ideally, what today's code should do is promote the concept of THE
> p2.data.area on the user's area or the machine itself, thus allowing for
> each install to share the bundle pool.
> What you are after is more or less the same thing than what the director
> application does when it is installing a complete product (see
> http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/p2_director.html).
> As I said the installer code is not supporting this as is, but it should be
> fairly straightforward for you to set this area once the location of the
> install has been filled in and before any profile registry access or profile
> creation is done.
>
> HTH
>
> PaScaL
>
> Fredrik Alströmer ---03/11/2009 05:36:53 AM---Hi again, I've played around a
> bit more with it, but I'm still stuck on the fact
>
>
> From:
> Fredrik Alströmer <roe@xxxxxxx>
> To:
> P2 developer discussions <p2-dev@xxxxxxxxxxx>
> Date:
> 03/11/2009 05:36 AM
> Subject:
> Re: [p2-dev] Provisioning p2 with p2?
> ________________________________
>
>
> Hi again,
>
> I've played around a bit more with it, but I'm still stuck on the fact
> that the p2 data area always end up within the installer or agent
> directories, how would I go about transferring the data area to the
> product being installed? (The config.ini even gets an absolute path to
> the data area of the installer, which is kind of ugly)
>
> This might be a dumb question, and obvious to everyone involved, but
> I'm lost! :)
>
> Thanks,
> Fredrik.
>
> On Fri, Mar 6, 2009 at 13:12, Fredrik Alströmer <roe@xxxxxxx> wrote:
>> Ok, thanks to all of you, I think I've got it now. Just one more
>> thing, is there a way to get the 'p2 disk layout' using standard
>> eclipse means (like, somewhere in the product export?), or would I
>> have to create and pack it up myself?
>>
>>> Also note that external provisioning can be done while a system is
>>> running.
>>
>> Should that read "can" or "can't"? Because from what I've heard, it's
>> always self-provisioning or provisioning of an external, non-running,
>> system. If it is indeed "can", how is the running system triggered to
>> update its enviroment? (by the way, in windows, bundles installed by
>> reference are locked and cannot be overwritten, wouldn't that be a
>> problem too?)
>>
>> Thanks,
>> Fredrik.
>>
>> On Thu, Feb 26, 2009 at 14:27, Henrik Lindberg
>> <henrik.lindberg@xxxxxxxxxxxxxx> wrote:
>>> Take a look at how the Eclipse SDK is laid out on disk when you have
>>> unzipped it.
>>> This is the configuration to use if you are writing your own RCP app that
>>> will maintain itself.
>>> In simple terms: the installation directory contains the p2 data area.
>>>
>>> A useful exercise is to look at how the p2-installer installs a
>>> stand-alone
>>> and a shared SDK.
>>> Look at the properties to see some of the things you can control.
>>> The director.app lets you do this as well, but then you are in full
>>> control
>>> of all the parameters - so you need
>>> to know what sort of layout you want and why,
>>>
>>> The central thing is the "p2 data area" - the location on disk where p2
>>> keeps its meta data.
>>> This data area can be used by any p2 "agent (i.e. running director,
>>> engine,
>>> etc...), i.e. an external installer, or
>>> an "embedded self updater". (If one is currently performing provisioning,
>>> it
>>> will lock files).
>>>
>>> Also note that external provisioning can be done while a system is
>>> running.
>>>
>>> If you want to build something and deliver it as a zip (the same way as
>>> the
>>> SDK), what you need to do is:
>>> a) build your thing,
>>> b) export it with generated meta data and artifact repositories
>>> c) install it using the director.app using a layout like the Eclipse SDK
>>> d) zip the directory where you did the installation.
>>>
>>> To make it "self managed" - you need to "include p2" in your application
>>> -
>>> which can mean including the same "machinery" and UI as in the Eclipse
>>> SDK,
>>> or that you create your own solution using the part of p2 that you need
>>> (i.e. your app does perhaps not need the advanced dialogs available in
>>> the
>>> SDK),
>>>
>>> There are (at least) two alternative ways of delivering your app;
>>> 1) instead of zipping an installed application, create the metadata and
>>> artifact repositories, and a separate installer (the p2-installer can be
>>> configured to install your app) - you then zip the repositories and the
>>> installer. The user unzips this, and then runs the installer which will
>>> install from the repositories that were included).
>>> 2) Just create the meta data and artifact repositories on your site,
>>> create
>>> a configuration of the p2-installer (or your own custom variation of such
>>> an
>>> installer), and zip only the p2-installer. The user downloads the
>>> installer,
>>> which will install from your update site.
>>>
>>> I hope this helps...
>>>
>>> Henrik Lindberg
>>> henrik.lindberg@xxxxxxxxxxxxxx
>>>
>>>
>>>
>>> On Feb 26, 2009, at 11:23 AM, Fredrik Alströmer wrote:
>>>
>>>> Basically, what I want is for one p2 instance to convey information to
>>>> the system being installed about what IUs have been installed and so
>>>> on, so that it may update itself later on, when it's running. That's
>>>> what I mean with autonomous. Currently, when I use the p2-agent to
>>>> create a profile and install a product, the profile description ends
>>>> up in the profile registry of the agent, not in the directory created
>>>> of the created profile...
>>>>
>>>> Given that this appears to be what is done with the eclipse sdk, it
>>>> should work. My second question was, is it possible to, with an
>>>> external p2 instance like the p2-agent, tap into this self contained
>>>> system and manage it (assuming it's not running of course)? This is
>>>> obviously true, I just need to make sure the p2-agent works with the
>>>> profile available in the installed system, rather than in its own
>>>> registry, the question is, how do I get the profile in there?
>>>>
>>>> Thanks,
>>>> Fredrik.
>>>>
>>>> On Thu, Feb 26, 2009 at 10:52, Haigermoser, Helmut
>>>> <Helmut.Haigermoser@xxxxxxxxxxxxx> wrote:
>>>>>
>>>>> Ciao Frederik :)
>>>>> Profiles can be "roaming", i.e. installable anywhere you want them to.
>>>>> Does that fit your definition of "autonomous"?
>>>>>
>>>>> What happens under the hood is at first launch the profile will look at
>>>>> itself and it's current install dir and modify itself to fit the new
>>>>> place.
>>>>> That's how eclipse SDK manages to be distributable by zip and yet come
>>>>> with
>>>>> a complete profile...
>>>>>
>>>>> HTH,
>>>>> Ciao, hh
>>>>>
>>>>> -----Original Message-----
>>>>> From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx] On
>>>>> Behalf Of Fredrik Alströmer
>>>>> Sent: Thursday, February 26, 2009 10:46 AM
>>>>> To: P2 developer discussions
>>>>> Subject: Re: [p2-dev] Provisioning p2 with p2?
>>>>>
>>>>> This is where I get lost, I understand that this might very well be the
>>>>> case (I found the profile registry in the p2 agent, which I'm using),
>>>>> but
>>>>> how would I go about to 'zip-up' my profile, which is done with the
>>>>> eclipse
>>>>> SDK as John described, and ship it off to somewhere else? Point being,
>>>>> I
>>>>> want my profile to be autonomous.
>>>>>
>>>>> If I'm able to achieve this, would I still be able to use a second p2
>>>>> agent to manage the now 'autonomous' system, as long as it's offline,
>>>>> or are
>>>>> these set-ups mutually exclusive (i.e. is an externally manageable
>>>>> autonomous system a contradiction in terms)?
>>>>>
>>>>> Thanks,
>>>>> Fredrik.
>>>>>
>>>>> On Thu, Feb 26, 2009 at 00:16, Henrik Lindberg
>>>>> <henrik.lindberg@xxxxxxxxxxxxxx> wrote:
>>>>>>
>>>>>> Hi,
>>>>>> The profiles are stored in a ProfileRegistry - and the implementation
>>>>>> used in p2 stores the profiles under "engine". Snoop around under the
>>>>>> "p2"
>>>>>> directory in your stand alone Eclipse SDK installation, or under
>>>>>> user.home/.p2 if you tried a SharedInstall.
>>>>>>
>>>>>> Henrik Lindberg
>>>>>> henrik.lindberg@xxxxxxxxxxxxxx
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Feb 25, 2009, at 4:47 PM, Fredrik Alströmer wrote:
>>>>>>
>>>>>>> Excellent, that's what I wanted to hear... Now I only need to figure
>>>>>>> out how to do this... ;)
>>>>>>>
>>>>>>> For the second part, that's what I meant, I was just curious whether
>>>>>>> an external p2 system (which is creating the profile) is actually
>>>>>>> able to convey information to the profile about IUs being installed
>>>>>>> and so on. I wasn't able to find a meta data repository (i.e. a
>>>>>>> description of the installed IUs) - only an artifact repository - in
>>>>>>> the profile I installed into, how does the p2 instance within the
>>>>>>> created profile know what it contains? Or does it simply backtrack
>>>>>>> and look for matching IUs to the artifacts?
>>>>>>>
>>>>>>> Or am I simply missing some magic here? :)
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Fredrik.
>>>>>>>
>>>>>>> On Wed, Feb 25, 2009 at 15:01, John Arthorne
>>>>>>> <John_Arthorne@xxxxxxxxxx>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Absolutely, p2 can and does do that. In fact our Eclipse project
>>>>>>>> builds run exactly in this way - p2 ant tasks are used to create a
>>>>>>>> profile, into which the platform or Eclipse SDK is provisioned. The
>>>>>>>> result is then zipped up and delivered on our downloads page. Also,
>>>>>>>> once you have installed the platform (which includes p2), p2 will
>>>>>>>> manage and be able to upgrade that (including itself). p2 can manage
>>>>>>>> a system that is not currently running, or it can manage a system
>>>>>>>> that it is currently running inside of.
>>>>>>>>
>>>>>>>> What you read about who touches what might have been taken out of
>>>>>>>> context.
>>>>>>>> What that means is that if the user unzips stuff manually into
>>>>>>>> eclipse/plugins or eclipse/dropins, then it is the user's
>>>>>>>> responsibility to "manage" those plugins manually at the file system
>>>>>>>> level (upgrade it, remove it, etc). p2 won't touch them. Things that
>>>>>>>> have been provisioned into eclipse/plugins or elsewhere by p2 via
>>>>>>>> the user interface or command line tools shouldn't be manually
>>>>>>>> edited/removed at the file system level by the end user (just like
>>>>>>>> you don't manually move/delete DLL's from Windows apps and expect
>>>>>>>> them to continue working).
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Fredrik Alströmer <roe@xxxxxxx>
>>>>>>>> Sent by: p2-dev-bounces@xxxxxxxxxxx
>>>>>>>>
>>>>>>>> 02/25/2009 08:38 AM
>>>>>>>>
>>>>>>>> Please respond to
>>>>>>>> P2 developer discussions <p2-dev@xxxxxxxxxxx> To p2-dev@xxxxxxxxxxx
>>>>>>>> cc Subject [p2-dev] Provisioning p2 with p2?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I think I read somewhere that, whatever is managed by p2 you
>>>>>>>> shouldn't touch, and whatever you manage p2 won't touch. This makes
>>>>>>>> perfect sense, however there's one thing that's not completely clear
>>>>>>>> to me. Is it one of the purposes of p2 to be able to create a new
>>>>>>>> profile (using p2, that is, like with the p2 agent), install p2 into
>>>>>>>> that profile, and then let it manage itself?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Fredrik.
>>>>>>>> _______________________________________________
>>>>>>>> p2-dev mailing list
>>>>>>>> p2-dev@xxxxxxxxxxx
>>>>>>>> https://dev.eclipse.org/mailman/listinfo/p2-dev
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> p2-dev mailing list
>>>>>>>> p2-dev@xxxxxxxxxxx
>>>>>>>> https://dev.eclipse.org/mailman/listinfo/p2-dev
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> p2-dev mailing list
>>>>>>> p2-dev@xxxxxxxxxxx
>>>>>>> https://dev.eclipse.org/mailman/listinfo/p2-dev
>>>>>>
>>>>>> _______________________________________________
>>>>>> p2-dev mailing list
>>>>>> p2-dev@xxxxxxxxxxx
>>>>>> https://dev.eclipse.org/mailman/listinfo/p2-dev
>>>>>>
>>>>> _______________________________________________
>>>>> p2-dev mailing list
>>>>> p2-dev@xxxxxxxxxxx
>>>>> https://dev.eclipse.org/mailman/listinfo/p2-dev
>>>>> _______________________________________________
>>>>> p2-dev mailing list
>>>>> p2-dev@xxxxxxxxxxx
>>>>> https://dev.eclipse.org/mailman/listinfo/p2-dev
>>>>>
>>>> _______________________________________________
>>>> p2-dev mailing list
>>>> p2-dev@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/p2-dev
>>>
>>> _______________________________________________
>>> p2-dev mailing list
>>> p2-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/p2-dev
>>>
>>
> _______________________________________________
> p2-dev mailing list
> p2-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/p2-dev
>
>
>
> _______________________________________________
> p2-dev mailing list
> p2-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/p2-dev
>
>
