[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fw: [p2-dev] Using the new "sofware site" target provisioner
- From: Darin Wright <Darin_Wright@xxxxxxxxxx>
- Date: Thu, 30 Apr 2009 09:06:31 -0500
- Delivered-to: firstname.lastname@example.org
> Hi Darin,
> I tested this and made the following observations:
> I stared by trying to add a "Sofware Site". I deliberately omitted to
> specify os/ws/arch. The result of this omission was that my platform
> defaults were used. That's not what I wanted. I need a platform that I
> can use for publishing features into a P2 repository. The features
> includes fragments from all possible platforms.
A target definition referencing software sites is backed by a p2 profile.
A profile is os/ws/arch specific. A target *definition* can take on a
specific os/ws/arch by specifying them explicitly or it can take on the
settings of the os/ws/arch it is installed in (by leaving them
unspecified). A target *platform*, or state (the result of resolving a
target definition) is os/ws/arch specific, as it always has been.
> Although you write that it doesn't make much sense, I still attempted to
> complement my target platform with a "Directory" where I had the
> delta-pack feature and tried again. Now, when it loads things from the
> "Software Site", I can see that it downloads the artifacts that are
> already present in the delta-pack (I can see them by checking the "Show
> Plug-in Content"). Wouldn't it be more efficient to let all types share
> a common bundle pool?
The delta pack works as before - you add it as separate directory. It is
true that there is some duplication between the delta pack and what gets
downloaded to the bundle pool. This was causing some trouble when
launching targets in the M7 test pass build (but has been fixed - see bug
274225). When resolving a target platform (i.e. build state) from a
definition, duplicate bundles are now rolled into one. The net result is
that a definition can point to arbitrary sources of bundles where
duplicates exist, but the resulting target state will only contain one.
The profile maintained for a target definition only contains IU's that are
specified from software sites. The additional locations (directories,
etc.), are not installed into the profile since we do not (necessarily)
have metadata to install them.
> Using a profile to manage a target platform doesn't sound right to me
> but perhaps I got it all wrong in respect to how to set up a target
> platform. What is the recommended approach given my requirements?
The end result is that we use a profile to manage the software sites
contained in a definition - the entire target is not maintained in a
profile. For this reason, you use the delta pack the same as before.
Moving forward, perhaps we can find some better ways to manage the
multi-platform scenarios. However, I think there is a difference between
development and deployment that should be noted here. Developers often use
target definitions/platforms to develop for a specific platform, whereas
build-meisters want to use them to deploy for all platforms.