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,
