Er. If that's true, then why have a libc-dev virtual package at all?
Granted, depending on:
libc6-dev | libc6.1-dev | libc0.2-dev | libc12-dev | libc4-dev
would certainly work (for all variants of libc I'm aware of right now,
anyway) - but would be a bit fugly.
freebsd-i386 has libc1-dev (glibc port) rather than libc4-dev (native libc) now. (This was an upstream decision by glibc developers.) libc1-dev provides libc6-dev, so I don't have a problem with this now. I would like to see it handled more cleanly, though.
If folks really aren't supposed to use libc-dev to mean 'the proper libc
for the current arch', maybe a substvar would resolve this?
Depends: ${libc-dev:Depends} ...
I like this idea. It's simple to use, and can be maintained in one place. I was going to suggest putting together a makefile snippet that people could include in debian/rules, but I like this better.
---Nathan