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 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120505132122.ga24...@falafel.plessy.net
