Christian Kurz <shorty@debian.org> wrote: > > flavours would be fine. But I'm not sure, if we really should keep those > modules inside the packages itself, which would then mean that every > developer has to keep track of it on his own, instead of having a > one debian package, where all possible modules are inside and which is > maybe maintained by the group of inetd maintainers. When a new inetd alternative is added, it would be easier for the maintainer to just add a module to handle that format than it would be for the update-inetd-modules package to include a new module. Too much package interdependance just makes things too cumbersome. > Yes, the general idea behind this, seems like a good solution. I think > the the details for the modules, the language to use and the decision > which packages include which part of this, would need to be discussed a > bit further. I was just throwing the idea in, I hadn't thought it all the way through to a spec and design. I'd expect people with more knowledge and experience than me to do that bit. What's more, I'm not really volunteering to do the work required (although I don't think I'd be needed *or* particularly helpful), so I can't very well say "This is the way it should be done!". -- Sam Couter | Internet Engineer | http://www.topic.com.au/ sam@topic.com.au | tSA Consulting | OpenPGP key ID: DE89C75C, available on key servers OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C
Attachment:
pgpUiYZDykSAT.pgp
Description: PGP signature