On Wed, 25 Oct 2006 19:44:38 -0700, Steve Langasek <[EMAIL PROTECTED]> said:
> On Wed, Oct 25, 2006 at 01:49:03PM -0500, Manoj Srivastava wrote:
>> > @@ -3195,8 +3112,8 @@
>> > <p>
>> > Additionally, packages interacting with users using
>> > <tt>debconf</tt> in the <prgn>postinst</prgn> script
>> > should
>> > - install a <prgn>config</prgn> script in the control area,
>> > - see <ref id="maintscriptprompt"> for details.
>> > + usually install a <prgn>config</prgn> script in the control
>> > + area, see <ref id="maintscriptprompt"> for details.
>> > </p>
>> >
>> > <p>
>> > You seem to have changed "should" to "should usually", and I
>> > don't see what the real difference is.
>> Not all packages have to install config files or be buggy -- for
>> example, packages that only ask questions based on information
>> available only after unpacking, for instance. Such packages may or
>> may not ask questions, and the question they ask may need values
>> gathered by programs that are contained in the package itself. In
>> this case, there can be no config file -- and all the questions are
>> conditionally asked in the postinst.
>> Since this is not the default, I use the term "should usually"
>> provide. not an unconditional should provide.
> However, I think it's important that policy outline those cases in
> which it's not a bug to omit a .config script.
I don't think I know _all_ use cases in which it is ok not to
add a .config file. I can provide a few use cases. I think the reader
should be allowed to make their own judgement calls, in case they
have a use case we might miss.
> Doesn't the absence of the .config script require additional by-hand
> handling of the templates which is otherwise done automatically
> through apt?
No. From debconf-devel (7):
,----
| A question is an instantiated template. By asking debconf to display a
| question, your config script can interact with the user. When debconf
| loads a templates file (this happens whenever a config or postinst
| script is run), it automatically instantiates a question from each tem‐
| plate. It is actually possible to instantiate several independent ques‐
| tions from the same template (using the REGISTER command), but that is
| rarely necessary.
`----
>> > <p>
>> > - Packages involving shared libraries should be split up into
>> > + Packages involving shared libraries ought to be split up into
>> > several binary packages. This section mostly deals with how
>> > this separation is to be accomplished; rules for files within
>> > - the shared library packages are in <ref id="libraries">
>> > instead.
>> > + the shared library packages are in <ref id="libraries">
>> > + instead.
>> > </p>
>> >
>> > <sect id="sharedlibs-runtime">
>> > I think the "should" there was good.
>> This is something I want to discuss further. Consider the case
>> where there is a package with a set of, say, 20 binaries with a lot
>> of common code, and upstream decided to abstract it out into a
>> shared lib. This is a shred lib used by anyone else, and it is
>> changing rapidly enough that there is the equivalent of a soname
>> change on every upload. There is no interest in supporting older
>> versions, or even having multiple versions of that lib. In this
>> case, either we can make packaging that software hard (since moving
>> the lib out of /usr/lib etc may involve some work), or we allow
>> some packages to include share libs in the package.
> This tells me that the guidelines for when shared library packages
> must be split up are still ill-defined in some corner cases. I
> don't think we should be gutting such an important requirement from
> policy just because there may be corner cases that need sorting,
> when the cost of non-compliance with this requirement is so high.
Making a SHOULD directive a suggestion is hardly what I call
gutting. However, since this is one area I was fuzzy about, and now I
have seen two strong negative reactions, and none in favour, this
seems like something that may be reverted.
manoj
--
"The Nazis have no sense of humor, so why should they want
television?" Philip K. Dick
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
