Bug#699749: [Pkg-utopia-maintainers] Bug#699749: Incompatible change in the ifupdown hooks interface
On 06.03.2013 00:20, Steve Langasek wrote: FWIW, I agree with Andrew that this isn't an interface change; this is a latent bug in the avahi hook which has merely been exposed by this behavior change in ifupdown. ifupdown supports more address families than ipv4 and ipv6 (specifically, it supports ipx); if a user had configured a system with only ipx interfaces statically configured (as unlikely as that would be in the 21st century), it appears that avahi would have misbehaved in the same way. A quick grep over all unpacked packages shipping ifupdown hooks show 60 hook scripts which don't have ADDRFAM set. I haven't checked them individually, though. I don't know why these --all calls are a useful thing for ifupdown to do, but I do think it's the responsibility of the avahi package to sensibly ignore values of $ADDRFAM that it doesn't understand. What I'm not happy about is, that such a change was made without notifiying the affected package maintainers *in advance* with clear instructions how to address this. Ideally via the BTS. Such documentation and instructions are still missing. Andrew, care to explain what a package maintainer is supposed to consider when shipping such a hook? The existing documentation is rather scarce on this topic. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#699749: [Pkg-utopia-maintainers] Bug#699749: Incompatible change in the ifupdown hooks interface
Hello. On 6 March 2013 13:45, Michael Biebl bi...@debian.org wrote: A quick grep over all unpacked packages shipping ifupdown hooks show 60 hook scripts which don't have ADDRFAM set. I haven't checked them individually, though. They usually check for interface name to match eth* or something, which is supposed to work. Somehow it did happen I haven't noticed avahi-daemon to have this thing, so that's why it's not fixed. Other packages I expect to work flawlessly. I don't know why these --all calls are a useful thing for ifupdown to do, but I do think it's the responsibility of the avahi package to sensibly ignore values of $ADDRFAM that it doesn't understand. What I'm not happy about is, that such a change was made without notifiying the affected package maintainers *in advance* with clear instructions how to address this. Ideally via the BTS. Such documentation and instructions are still missing. http://lists.debian.org/debian-devel/2012/04/msg00448.html By the way, quoting myself, “Network Manager already uses similar approach, so if anything can break, it's been broken for a long time already.” Andrew, care to explain what a package maintainer is supposed to consider when shipping such a hook? The existing documentation is rather scarce on this topic. Handle what you can, ignore everything else. Check ADDRFAM, METHOD or interface name (unreliable a bit) and decide if you need to continue execution or not. It'd be easier to give recommendations if I knew what exactly is unclear in the documentation, I've tried to explain thing to be easily understandable. -- WBR, Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699749: [Pkg-utopia-maintainers] Bug#699749: Incompatible change in the ifupdown hooks interface
Hi, On 06.03.2013 15:21, Andrew Shadura wrote: Hello. On 6 March 2013 13:45, Michael Biebl bi...@debian.org wrote: A quick grep over all unpacked packages shipping ifupdown hooks show 60 hook scripts which don't have ADDRFAM set. I haven't checked them individually, though. They usually check for interface name to match eth* or something, Checking for hard-coded interface name sounds like a terrible idea. Especially in hindsight of tools like biosdevname or the new interface naming scheme in udev. which is supposed to work. Somehow it did happen I haven't noticed avahi-daemon to have this thing, so that's why it's not fixed. Other packages I expect to work flawlessly. When you say expect, does that mean you didn't actually check those hook scripts individually? I don't know why these --all calls are a useful thing for ifupdown to do, but I do think it's the responsibility of the avahi package to sensibly ignore values of $ADDRFAM that it doesn't understand. What I'm not happy about is, that such a change was made without notifiying the affected package maintainers *in advance* with clear instructions how to address this. Ideally via the BTS. Such documentation and instructions are still missing. http://lists.debian.org/debian-devel/2012/04/msg00448.html This is all nice, but you can't expect every maintainer to read debian-devel. So a bug report for affected package maintainers would have been nice. Ideally user-tagged etc, so progress can be monitored. By the way, quoting myself, “Network Manager already uses similar approach, so if anything can break, it's been broken for a long time already.” Not sure what this quote is supposed to mean and why you bring up NM in this context. Andrew, care to explain what a package maintainer is supposed to consider when shipping such a hook? The existing documentation is rather scarce on this topic. Handle what you can, ignore everything else. Check ADDRFAM, METHOD or interface name (unreliable a bit) and decide if you need to continue execution or not. It'd be easier to give recommendations if I knew what exactly is unclear in the documentation, I've tried to explain thing to be easily understandable. I guess what I'm missing is a section in the ifup or interfaces man page called ifupdown for package maintainters and how to integrate your service with ifupdown. With recommendations, examples, best practices, etc. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#699749: [Pkg-utopia-maintainers] Bug#699749: Incompatible change in the ifupdown hooks interface
Hello, On Wed, 06 Mar 2013 20:26:47 +0100 Michael Biebl bi...@debian.org wrote: On 6 March 2013 13:45, Michael Biebl bi...@debian.org wrote: A quick grep over all unpacked packages shipping ifupdown hooks show 60 hook scripts which don't have ADDRFAM set. I haven't checked them individually, though. They usually check for interface name to match eth* or something, Checking for hard-coded interface name sounds like a terrible idea. Especially in hindsight of tools like biosdevname or the new interface naming scheme in udev. Yes, but that's a different bug. which is supposed to work. Somehow it did happen I haven't noticed avahi-daemon to have this thing, so that's why it's not fixed. Other packages I expect to work flawlessly. When you say expect, does that mean you didn't actually check those hook scripts individually? When I say expect I mean I did actually check, but I could however miss something. I don't know why these --all calls are a useful thing for ifupdown to do, but I do think it's the responsibility of the avahi package to sensibly ignore values of $ADDRFAM that it doesn't understand. What I'm not happy about is, that such a change was made without notifiying the affected package maintainers *in advance* with clear instructions how to address this. Ideally via the BTS. Such documentation and instructions are still missing. By the way, quoting myself, “Network Manager already uses similar approach, so if anything can break, it's been broken for a long time already.” Not sure what this quote is supposed to mean and why you bring up NM in this context. NM has been feeding ifupdown hooks with such unusual values for ages. I guess what I'm missing is a section in the ifup or interfaces man page called ifupdown for package maintainters and how to integrate your service with ifupdown. With recommendations, examples, best practices, etc. As I plan a serious rewrite of the hooks system soon anyway, I think I will just write a new manual on that regard. -- WBR, Andrew signature.asc Description: PGP signature
