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

Re: First draft of review of policy must usage

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.
vorlon@debian.org                                   http://www.debian.org/

Reply to: