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
