← Back to team overview

maas-devel team mailing list archive

Re: DHCP packaging

 

On 20 September 2012 14:44, Andres Rodriguez
<andres.rodriguez@xxxxxxxxxxxxx> wrote:
>> >  * maas
>> >    - Depends: python-django-maas, python-maas-provisioningserver,
>> > maas-region-controller, maas-cluster-controller
>> >  * python-django-maas
>> >    - Installs: src/maasserver, src/metadataserver
>> >  * python-maas-provisioningserver
>> >    - Installs: src/provisioningserver
>>
>> We could merge these into a single package, python-maas, say? That
>> won't make a lot of difference to disk usage, but perhaps it's
>> distasteful, or unclean?
>
> Currently it is all under python-django-maas. I can leave it as is...
> but maybe it is better to separate the code as it servers completely
> different purposes.

A lot of that code is not Django related, so renaming or splitting
would make sense.

>
>>
>> >  * maas-region-controller:
>> >    - Installs: maas-txlongpoll upstart job, installs DB, installs
>> > apache2, etc.
>> >    - Depends: python-django-maas, python-maas-provisioningserver
>> >  * maas-cluster-controller
>> >    - Installs: maas-pserv, maas-celery upstart job
>> >    - Depends: python-maas-provisioningserver
>>
>> Add to that a package for the CLI, which is designed to be installed
>> on its own. maas-region-controller and maas-cluster-controller should
>> depend on it.
>
> I don't think they should depend on it. Package A depends on package B
> when A needs B in order to function properly. In this case, if we don't
> have the CLI non of those two packages will lose functionality. I think
> it should be a Suggests.

My plan is that maascli will replace both the maas and maas-provision
commands, and be renamed maas itself. When maas-region-controller and
maas-cluster-controller are installed they can drop a file into, say,
/etc/maas/cli.d to point the new maas executable to their additional
functionality. In other words they will have a hard dependency on
maas-cli.

>
>>
>> Fwiw, the CLI bundles client API code, so it may be worth renaming the
>> maas-cli package to maas-client, to indicate that it comes with both a
>> CLI and client libs. Or... because the client code is Python, we could
>> have:
>>
>>   * maas-cli
>>     - Depends: python-maas-client
>>   * python-maas-client
>>     - Installs: src/apiclient
>>
>> That's even more work, so up to you.
>
> The latter is what I wanted to do at first but decided to ship
> everything in the same package to try to avoid having yet another
> package. But I really don't mind doing it this way.

For now let's stay with what we've got.

>
>>
>> >
>> > Now, I think it would be a good idea to create a different packaging
>> > branch, such as: lp:~maas-maintainers/maas/packaging.cluster, which is
>> > stacked on top of lp:~maas-maintainers/maas/packaging, so others can
>> > work on it and we can also benefit from fixes that hit the packaging
>> > branch.
>>
>> I assume you don't mean "stacked" in the bzr sense?
>> >
>> > Either way I'd like to upload a new release to the Archives *before* we
>> > go ahead with the package split.
>>
>> Once that upload has been made, what need is there for another branch?
>> We have history if we need to go back.
>
> Once the final pre-split package is uploaded, then we do not need
> another branch.

Cool. I think it'll be better if we stick with the same branch.


References