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

Re: Policy rewrite: chaps 7-10



On Thu, Mar 15, 2001 at 03:00:14AM +0100, Wichert Akkerman wrote:
> Previously Julian Gilbey wrote:
> > 7.2 Binary dependencies
> >     This section states that "All but Pre-Depends and Conflicts take
> >     effect only when a package is to be configured."  But actually,
> >     dpkg appears to ignore everything except for (Pre-)Depends,
> >     (sometimes) Recommends and Conflicts.  So what should this say?
> 
> It should say what it currently says.

But what does it mean for a "suggests to take effect"?

> > 7.2 Depends: should also mention "or if it is required by the
> >     postinst, prerm or postrm scripts".
> 
> Remove postrm from there, that can't rely on the Depends being present.

So we should say that somewhere; it's probably important:
  The postrm must not depend on any non-essential package.

> > 7.5 States:
> >       Virtual packages (Section 7.4, `Virtual packages - `Provides'') are
> >       not considered when looking at a `Replaces' field - the packages
> >       declared as being replaced must be mentioned by their real names.
> >     But does it in a Provides/Conflicts/Replaces scenario, as
> >     described in 7.5.2?
> 
> P/C/R is really a special case.

OK, so then the opening paragraph needs clarifying, eg, something like
"(Note that the P/C/R case described in 7.5.2 is a special case in
which virtual packages are considered.)"

> > 7.5.1 States:
> >       In the future `dpkg' will discard files which would overwrite those
> >       from an already installed package which declares that it replaces the
> >       package being installed.  This is so that you can install an older
> >       version of a package without problems.
> >     Has this now happened?
> 
> What do you mean? This has always been true.

That's what the text currently says, taken straight from the old
packaging manual, AFAIK.

So should the text read just: "`dpkg' discards files which ..."?

> > Chapter 9
> >     Should mention that ld.so might actually be ld-linux.so or
> >     something else instead.
> 
> It could be anything basically, especially if you start thinking about
> Debian GNU/HURD or BSD versions.

Agreed, so we should say something about this, perhaps only in a
footnote.

> > 9.2.2 Should say what dpkg-shlibdeps actually does if we're going to
> >     say anything at all.
> 
> The footnote should be zapped and the merged into the real text. What
> it says won't be entirely correct either once I replace dpkg-shlibdeps
> with the python versions.

Agreed.  This is yet another place where the current policy is
describing tools rather than policy.

> > 9.2.* Do we need /etc/dpkg/shlibs.default any longer?
> 
> Yes.

OK.

> > 10.1.2: Surely directories should be removed by postrm, not prerm?
> >      (Prerm may not always be called, eg if a package disappears.)
> 
> Either might happen.

What do you mean?  Maybe I wasn't clear.  The text suggests that
directories in /usr/local must not be in the .deb, but must be created
in the postinst and removed in the prerm; I asked why the prerm and
not the postrm.  Actually, there is a reason: the postrm may not be
called if there's an error-unwind situation.

Which is better to do: prerm, postrm or leave it up to the maintainer?

> 10.3.1: needs to be rewritten for LSB complience which defines
> specific runlevels.

OK, if you can give some pointers or details, that would be good.

> > 10.3.2: Hard question:
> >     Not all of start, stop, restart etc. are relevant for everything
> >     in /etc/init.d, for example checkfs.sh.  We should figure out a
> >     way of distinguishing between daemons (which should accept all of
> >     these) and specific startup/shutdown scripts (which needn't).
> 
> Daemon or non-daemon is a really bad measure. 

Fine.  Do you have any ideas of what the measure should be?  I don't.
I just know we need one.

> > 10.3.2: Should "The start, stop, restart and force-reload options
> >      should be supported" be replaced by "must be supported",
> >      contingent on the above suggestion?
> 
> I don't think force-relead must be supported, restart already does
> the same thing. The other three should be a must though.

OK.

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

         Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
       Debian GNU/Linux Developer,  see http://people.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/



Reply to: