Thinking again about MidCOM3 package management
-
Henri Bergius
Thinking again about MidCOM3 package management
Wed March 18 2009 09:45:04 UTCHi,
Here are some quick notes I wrote down last night:
"Like it or not, the mere tagging of a source tree has now become a valid option for releasing software"
<http://times.usefulinc.com/2008/06/16-ops-now>
* New installer tool written in Python that can support both git and SVN
* Each package is a git repo or SVN URL (with optional branch or tag name to specify version)
- Releases are made just by tagging or branching
* Make a checkout to `<install prefix>`share/midgard/`<repo type>`
* Check `manifest.yml` for dependencies, and install those
* Symlink files based on MidCOM's standard hierarchy to various places
* Python libs for git and SVN:
* http://gitorious.org/projects/git-python/
* http://pysvn.tigris.org/
Usage:
# midgard-package install https://svn.midgard-project.org/midgard/trunk/midcom/midcom_core/
# midgard-package install git://github.com/bergie/net_nemein_calendar.git
What do you think? Would be interesting to discuss in Linköping.
--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/
Skype: henribergius
Jabber: henri.bergius@gmail.com
Microblog: http://www.qaiku.com/home/bergie/
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] Thinking again about MidCOM3 package management
Wed March 18 2009 10:50:08 UTC2009/3/18 <henri.bergius@iki.fi>:
> # midgard-package install https://svn.midgard-project.org/midgard/trunk/midcom/midcom_core/
> # midgard-package install git://github.com/bergie/net_nemein_calendar.git
would be nice, to also have something like pear's channenls or ruby's gem-lists.
so, we could just use "midgard-package install core"
--
Alexey Zakhlestin
http://www.milkfarmsoft.com/
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] Thinking again about MidCOM3 package management
Wed March 18 2009 12:45:09 UTCAlexey Zakhlestin writes:
Hi!
> 2009/3/18 <henri.bergius@iki.fi>:
>
>> # midgard-package install https://svn.midgard-project.org/midgard/trunk/midcom/midcom_core/
>> # midgard-package install git://github.com/bergie/net_nemein_calendar.git
>
> would be nice, to also have something like pear's channenls or ruby's gem-lists.
> so, we could just use "midgard-package install core"
Fully agree. I, as a user, want to install org_routamc_gallery and I
really do not care where and how it's downloaded from.
Piotras
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] Thinking again about MidCOM3 package management
Sat March 21 2009 21:05:06 UTC-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
Some discussion and a plan for the MidCOM3^WMidgard2 MVC package
management. Below a snapshot from http://etherpad.com/f7ioYW6ion , where
we have discussed it now during the gathering:
Packaging
# Situation at the moment
* We use pear packaging and it has a lot of problems
# Bergies idea
"Like it or not, the mere tagging of a source tree has now become a
valid option for releasing software"
<http://times.usefulinc.com/2008/06/16-ops-now>
* New installer tool written in Python that can support both git and SVN
* Each package is a git repo or SVN URL (with optional branch or tag
name to specify version)
* Make a checkout to `<install prefix>`share/midgard/`<repo type>`
* Check `manifest.yml` for dependencies, and install those
* Symlink files based on MidCOM's standard hierarchy to various places
* If there are changes to MgdSchema file, run midgard-schema (or do the
same via Midgard API directly), stop/start Midgard processes
* Python libs for git and SVN:
* http://gitorious.org/projects/git-python/
* http://pysvn.tigris.org/
# midgard-package install
https://svn.midgard-project.org/midgard/trunk/midcom/midcom_core/
# midgard-package install
git://github.com/bergie/net_nemein_calendar.git
* Make an installer that sniffs svn / git -repo and as soon as someone
commits to the repo and changes the version numbering, installer makes a
new package
** What's "make a new package" supposed to mean in the context of the
installer? If a release is a tag, wouldn't making a package be a
post-commit hook that creates the tag when a version number is bumped.
* Every midcom package has manifest written in YAML that can be read by
python or php. From there we get the dependencies
* Up's
** Easy way to set up the difference with production server and
development server (package state)
* Downs
** Are there any??
** We need to actually write the tool
* Channels
** What a user most of the time wants to say is midgard-package install
org_routamc_positioning, not
https://svn.midgard-project.org/midgard/trunk/midcom/org_routamc_positioning/
*** Therefore, we should either have a default prefix if argument is not
a repository path(ugly), or some kind of a concept of channel, and the
default channel being https://svn.midgard-project.org/midgard/trunk/midcom/
*** Suppose we have a bunch of (related) components we don't want in the
midgard repo, and we have them in repo x, it would be nicer to say once
'midgard-package channel add
https://svn.example.com/project/trunk/midcom' and after that
'midgard-package install examplechannel:com_example_component', where
"examplechannel" would be gotten from some kind of manifest file in that
repo
** Listings of available components would be more handy to get with a
channel model
The Plan:
backend:
* this is about automating things on m-p.org. Others can maintain their
channel files how they please
1. post-commit hook looks for changes to component manifests based on
channel-config.yml
2. if a version number is bumped, and a corresponding tag doesn't exist,
it is created. If it exists, that component's current state is copied
under that tag.
3. channel files (/channels/*) are updated.
* Each channel file is looked at, and if the new version matches that
channel's version pattern, that version of that package is added to the
channel file.
https://svn.midgard-project.org/midgard/channels/vinland.yml:
name: vinland
type: svn
channel-source: #optional, for m-p.org channel maintenance operations
tags: 9-03-*
paths: /branches/vinland/midcom/
# only when packages matching the version and path patterns are version
# bumped, are they added to this channel, so we can have e.g.
vinland and
# vinland-contrib
url: https://svn.midgard-project.org/midgard/channels/vinland.yml
#if URL changes, 'midgard-package update' reading the channel can prompt to
# change the URL in /etc/midgard/midgard-package.yml
components:
org_routamc_positioning:
description: Location support # should this be here?
# Should be taken from the component's
# manifest automatically, but
should the
# trunk's description used for all
# versions?
versions:
9.03.RC1:
url:
https://svn.midgard-project.org/midgard/tags/9-03-RC1/org_routamc_positioning/
dependencies:
org_openpsa_httplib:
version-min: 9.03
version-max: 9.03.5 # optional, if missing for a
# midgard package, same
generation
# will be accepted, i.e. 9.03.*
# but not 9.09, but can be
forced?
source-type: midgard
source-channel: this # should this be here?
should it
# be optional? 'this' would
# indicate that the package is
# present on the current
channel.
# otherwise it would be a URL
# to a channel file.
Pear_Package:
version-min: 6.18
source-type: pear
source-channel: pear.php.net
9.09.5:
...
client:
* 'midgard-package channel add
https://svn.midgard-project.org/midgard/channels/vinland.yml'
** channel is added to config file
** channel is fetched and cached under /var/lib/midgard/channels/vinland.yml
* 'midgard-package update'
** channel files are re-fetched
* 'midgard-package install [channel:]<package>[=version]|<url>'
** newest version available for specified channel is installed
** data about installation is saved in
/var/lib/midgard/channels/installed_packages.yml
* 'midgard-package upgrade <package>|all'
** upgrade only looks at the channel the package was installed from
** if newer version is available in another channel than package was
installed from, and that version is wanted, it should be done by
midgard-package install
* 'midgard-package list [channel]'
* 'midgard-package list-all'
** these also list installed packages from outside of channels
** output:
com_rohea_facebook:
installed: 9.03.0 (vinland)
available in: vinland, mjollnir, devel
latest: 9.03.3 (vinland), 9.09.2 (mjollnir), 10.03.beta-1 (devel)
* 'midgard-package info <package>' for more detailed info
/var/lib/midgard/channels/installed_packages.yml
com_example_component:
version: 9.03.7
channel: none
type: git
url: git://example.com/repo/component/ # the last three should be
here to
# keep track of components
# installed from outside repos
...
/etc/midgard/midgard-package.yml:
# with each new generation release the default version of this file gets
that generation's channel contrib-channel
default-channel: vinland
channels:
devel:
type: svn
URL: https://svn.midgard-project.org/midgard/channels/devel.yml
vinland:
type: svn
URL: https://svn.midgard-project.org/midgard/channels/vinland.yml
mjollnir:
type: svn
URL: https://svn.midgard-project.org/midgard/channels/mjollnir.yml
- --
Patrik Hirvinen
patrik.hirvinen@nemein.com
+358-(0)40-7307117
http://nemein.com/fi/people/hirvinen/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEAREDAAYFAknFVcAACgkQiCIKn84rIOgfRQCeIgf3zNqI3UA/EPWX2XcjLYoe
NTYAn25pUM5Q4EAkmL06uqE9nj8K+2Vp
=GnHC
-----END PGP SIGNATURE-----
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
