Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 367829 - [nano] separate Gemini Web out of the smallest nano distribution
Summary: [nano] separate Gemini Web out of the smallest nano distribution
Status: CLOSED FIXED
Alias: None
Product: Virgo
Classification: RT
Component: runtime (show other bugs)
Version: 3.1.0.M01   Edit
Hardware: PC Mac OS X - Carbon (unsup.)
: P3 normal (vote)
Target Milestone: 3.5.0.M02   Edit
Assignee: Borislav Kapukaranov CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-04 06:04 EST by Glyn Normington CLA
Modified: 2012-01-05 13:05 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Glyn Normington CLA 2012-01-04 06:04:04 EST
There is clearly a usecase for a nano-based, single region distribution including Gemini Web (GW) like the VN in 3.1.0.M01 (known informally as 3.5.0.M01), but also for a very small nano-based, single region distribution for users who find the kernel too heavy.

So GW should be separated out of the basic VN distro and then added back in higher up the stack to form another distribution.

So we'll end up with multiple stacks, something like this:

  VN+GW VTS  VJS
    |    |    |
    \    \    /
     \    \  /
      \    VK
       \   |
        \  |
         \ |
          VN

Note that this could have implications for rippling and releasing since we may no longer be able to get away with one long linear list of git repositories.
Comment 1 Borislav Kapukaranov CLA 2012-01-05 13:05:16 EST
Fixed with commits:
nano - 7225109
web-server - ffb2873

As a result there are two nano packages now:
- The smallest possible (VN without p2 and without GW)
- Full (VN + p2 + GW)

The commit in web-server allows the scripts to upload both zipped distributions to build or download.eclipse.org.

This has no impact on the linear approach of how Virgo is built. What's important is that the packaging repositories chain remains unchanged and is unlikely to change as the chain isn't related with how many packages a packaging repository produces.