Re: Packaging python-mocker and cloud-init in Debian ?
Hi again,
I think that the best start would be to upload a lean version of cloud-init,
see below for details. Would it inflict you a significant work overhead ?
Le Fri, May 04, 2012 at 03:18:45PM -0400, Scott Moser a écrit :
> On Fri, 4 May 2012, Charles Plessy wrote:
> >
> > - In the cloud-init packiage they are used to disable ureadahead. Isn't
> > there a more propre way for package A to disable a service provided
> > by package B ? If ureadahead must never run when cloud-init is
> > installed, its upstart job could test if cloud-init is installed and
> > exit in that case. Or, if ureadahead and cloud-init should not be
> > installed together, wouldn't a simple Conflicts: statement solve the
> > problem ?
>
> Disabling of readahead via diversion is the correct path in my opinion.
> ureadahead is a dependency of 'ubuntu-minimal'. So that is why we've not
> conflicted with it.
>
> ureadahead does not make sense in any virtual machine. cloud-init was
> designed to run in virtual machines... so we disable it.
I sampled opinions on the matter on debian-mentors, and the one answer I had
for the moment is also supporting that it is ureadahead that should contain
what is necessary for not running in presence of cloud-init.
I can keep the current Ubuntu code in the Debian package, but if somebody would
upload ureadahead to Debian, I think that would made cloud-init seriously buggy
according to Debian's policy. So if possible, I would prefer to keep the code
out.
> > - In the grub-legacy-ec2, diversions are used to take over grub-set-default
> > from grub-legacy or grub2-common. These two packages manage this
> > situation by conflicting with each other. Wouldn't it be simpler to
> > also conflict with grub-legacy and grub2-common, or are there situations
> > where they should be installed together ?
>
> grub-legacy-ec2 does conflict with grub.
> grub-legacy-ec2's purpose in life is to manage /boot/grub/menu.lst without
> worrying about installing a bootloader. This is because EC2 instances
> typically boot via pv-grub, which is a grub-alike that lives outside the
> image, but reads /boot/grub/menu.lst from inside the image.
>
> It explicitly does not conflict with grub-pc so you can create one image
> (like one from cloud-images.ubuntu.com) that can run with grub-pc as the
> bootloader or pv-grub as the bootloader.
On Debian Sid, grub depends on grub-pc, which is grub 2. So cloud-init in
Debian should at least be corrected to conflict against grub-legacy. For the
use of grub-pc and grub-legacy-ec2 at the same time, do you forsee cases where
there would need different defaults for grub-legacy-ec2 and grub-pc ?
I think that your proposition to separate grub-legacy-ec2 is good, especially
that in Debian, the plan is to maintain cloud-init in the python applications
packaging team, and grub-legacy-ec2 has nothing to do with Python.
It looks like ideally, the functions of grub-legacy-ec2 could be attached to
the grub2 package so that they can share their configuration. How about if I
contact the grub2 maintainers and tell about the need to create menu.lst in
pv-grub-booted systems, proposing grub-legacy-ec2's code as a starting point ?
Have a nice day,
--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan
Reply to: