MDS2

= MDS2 =

MDS2 uses a different manner of accessing repositories and source code than MDS1. This means that instead of accessing Mer:MDS:Core:i586, you access Mer:MDS:Core:i586:

Instead of using a individual checkout, MDS2 uses the git repositories directly and allows individual downloads of binary releases.

= Administration commands =

In the following, HOST:PORT is the host and port of the MDS2 server:

curl http://HOST:PORT/update/packages/

What this will do is look in mappings.xml, find the relevant project mapping, and then rsync update from packages-upstream to packages-path. This will bring the packages-path directory up to date, and make the relevant version/tag/branches available through OBS protocol.

curl http://HOST:PORT/update/repo/ /

What this will do is look in mappings.xml, find the relevant project mapping, then rsync from the binaries-upstream the binary repositories named :*: into 'binaries' directory. This makes it available for binary repository access through OBS protocol.

= MDS2 in Mer Community OBS =

The MDS2 sits on cmds:8002 on the cmds host, within /data/mds

When a new Mer release or prerelease comes in, you need to first sync the local copy of the git repositories, which includes the Mer Core in git.

curl http://cmds:8002/update/packages/Core

This will synchronise the git repositories and as one of the effects, make the sources for the new release available in mer:mds2:Core:ARCH:

Next up, you need to import the individual release:

curl http://cmds:8002/update/repo/Core/

This will rsync down the individual binary release locally. Now over OBS api this version has binary repositories available for mer:mds2:Core:ARCH:

So how do we update so that people take the new version into use?

mer:devel serves as "This project serves as a convenient pointer to the mer core project in the mds2 instance".

You then modify the 'next' pointers in that meta prj to the version you'd like it to within MDS2.