[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#267142: huh?



> A shell with a crazy debconf builtin [that is, a shell with a builtin
> called "debconf" that does something very different from the Debian
> "debconf"] is still a POSIX compatible shell [that is, provided it
> otherwise is, such a builtin is allowed for a POSIX compatible shell],
> and so the "should" advice in Policy 10.4 kicks in [that is, the
> requirement that one's scripts should work on any POSIX compatible
> shell], and one should not use debconf [expecting to get the Debian
> behavior, because a POSIX compatible shell can have a debconf builtin
> that does something wildly different] (or use it through a complete
> path name) [because of course this will avoid any builtin, though is
> itself contrary to policy 6.1].
> 
> I'd be happy to explain in more detail, but you'll have to say which
> part you didn't understand. 

No, that was better.  I don't think it's accurate to consider "debconf"
a non-POSIX shell feature upon which maintainer scripts rely unless such
maintainer scripts rely on the enhancements present in the pdksh-specific
"debconf" builtin.

> I find your oneliner replies very annoying; if you would spend the
> time to give your thoughts more completely it would vastly speed up
> the discussion and make it far less difficult for me.

Hmm.

> Do you have an alternative way to specify what features a maintainer
> script may rely on?  I proposed several in my original report that
> would all do the job.

I would be more specific about what "POSIX" means in 10.4, but I don't
think that would solve your problem.



Reply to: