Hello, On Wed, 13 Apr 2011 22:28:54 +0200 Luk Claes <l...@debian.org> wrote:
> > If it's the only case, it should be specified explicitly. And, after > > all, why not use the utility that is supposed to be used, and not > > this hackish thing? > The only reason it was implemented this way is because bash is still > essential and so does not need a dependency. So you prefer not to specify dependencies at all and break the install than to specify the dependency explicitly? I don't grok this, sorry :( > > Also, there's no way to get a newer bash unless I install it by > > hand. This system isn't lenny any more, but nothing has upgraded it > > yet by means of dependencies. > Well, we only guarantee to support upgrades from stable to the next > one. Obviously we will try to not break things in unstable and > testing. Though it's not uncommon to make the assumption that users > have at least upgraded to stable before doing partial upgrades to > unstable/testing versions. This machine is (obviously) a server. I can't 'just upgrade' it to the stable at once, so I do partial upgrades. Dist-upgrade is no go at this moment. So in my attempt to get NFS over IPv6 working I got broken NFS at all :( > Anyway, using a really old packaged bash, a newly packaged bash or a > self compiled bash (even the version in lenny) should all work for > this /dev/tcp use. It's bash 3.2-4 from lenny, it's not so old. And it doesn't have /dev/tcp support. > It can also be replaced by 'lsof -i :111' or > something netcat like, though for both these you need to make sure > you have lsof or netcat installed. It could be replaced by rpcinfo (as suggested before) which is provided by libc-bin, so no extra dependencies and no breakage. Why not? Why such a resistance? -- WBR, Andrew
signature.asc
Description: PGP signature
