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. Doesn't the absence of the .config script require additional by-hand handling of the templates which is otherwise done automatically through apt? > > <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. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
