Re: Packaging python-mocker and cloud-init in Debian ?
On Fri, 4 May 2012, Charles Plessy wrote:
> Le Thu, May 03, 2012 at 11:24:34AM -0400, Scott Moser a écrit :
> >
> > My goal would be to keep minimal changes from debian to ubuntu, and the
> > code there does not cause any issues that i'm aware of if there is no
> > readahead installed. Is there some policy that explicitly calls that out?
>
> For ureadahead in particular, I was worried that it could cause problems as the
> package does not exist in Debian. After reading how diversions work (I never
> used them before), it looks like it would be harmless to keep that
> Ubuntu-specific code in the package for Debian.
>
> But more in general, I wonder if diversions are the good tool here.
>
> - 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.
cloud-init has recently been running more on real hardware, where
re-enabling ureadahead might make sense. I just opened a bug for that at
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/994698 , but
I consider it pretty low priority.
>
> - 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.
> I am now looking at update-grub-legacy-ec2. It uses debconf and ucf directly,
> wich make the package more complex (and will trigger extra work for the
> translations). It looks like this was carried over from Ubuntu's grub-legacy
> package. Is it still necssary in grub-legacy-ec2's context ? Otherwise, I
> would be tempted to remove that part, in order to simplify the package.
We could separate grub-legacy-ec2 into its own source package, I would
support doing that, but its presense is necessary as described above.
Reply to: