Re: Packaging python-mocker and cloud-init in Debian ?
On Sat, 5 May 2012, Charles Plessy wrote:
> 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 agree that it would be better to have ureadahead "know" that it
shouldn't run. I'll chase that a bit.
>
> 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.
which policy would that be? IIRC, I was advised to do the dpkg-divert by
an experienced debian developer.
> > > - 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
I think you meant 'grub-legacy-ec2' in debian should be corrected to
conflict against grub-legacy. (not cloud-init, but grub-legacy-ec2). I
agree with that.
> 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'm sorry, I'm not sure what you mean by 'defaults'.
If you mean which kernel to boot, there is some unfortunate code in
grub-legacy-ec2 that explicitly ignores certain kernels by kernel name
because they're known not to boot (due to buggyness of kernel, not
config... thats largely historical).
> 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 ?
I think that sounds like a good idea.
> Have a nice day,
Reply to: