Re: Packaging python-mocker and cloud-init in Debian ?
On Wed, 9 May 2012, Charles Plessy wrote: Le Sat, May 05, 2012 at 01:29:24PM -0400, Scott Moser a écrit : On Sat, 5 May 2012, Charles Plessy wrote: 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. Hi again, I proposed the idea to the grub2 maintainers in http://bugs.debian.org/672104. I spoke to Colin Watson about this today, and he suggested that grub2 was not the right place for this. But, he would help/sponsor a grub-legacy-ec2 package into debian. So I think we'll chase that. In the meantime, I consider uploading a version of cloud-init where grub-legacy-ec2 and all the diversions have been removed. Would this make your work hader in Ubuntu ? As long as you're willing to work towards a unified package in the future, I'm not opposed to that. The biggest missing piece is the sysvinit scripts. I don't think you added any, did you? Have a nice day, Thanks for your help, Charles. Scott
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,
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.
Re: Packaging python-mocker and cloud-init in Debian ?
On Thu, 3 May 2012, Charles Plessy wrote: I have injected cloud-init to the python-apps repository (thanks to the admins). I am currently studying how it works, and have done a couple of cleanings and updates on low-hanging fruits. Any help will be much appreciated ! http://anonscm.debian.org/viewvc/python-apps/packages/cloud-init/trunk/debian/?view=log Thanks. I'm fine with all the changes I see there other than http://anonscm.debian.org/viewvc/python-apps/packages/cloud-init/trunk/debian/cloud-init.postrm?revision=8606view=markuppathrev=8607 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? -- 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/alpine.DEB.2.02.1205031118580.4667@brickies
