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.
