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

Re: Working on debian developer's reference and "best packaging practices"



On Fri, May 10, 2002 at 04:02:47AM +1000, Anthony Towns wrote:
> On Mon, May 06, 2002 at 06:19:54PM +0100, Julian Gilbey wrote:
> > > > Then each section could either have the structure:
> > > >   Policy dictate s
> > > >   Discussion, useful information, guidelines, examples
> > > > or we could merge them, and have policy dictates all in the form MUST,
> > > > SHOULD, MAY, MUST NOT, etc., as in the RFCs. 
> > > I'm quite confident that trying to differentiate between requirements
> > > and guidelines like this will turn out to be completely unhelpful and
> > > a large waste of time, personally.
> > Don't RFCs do this frequently?  And I've never heard people making
> > such a complaint about them.
> 
> RFCs have a different goal to -policy. RFCs specify things that get
> implemented by different groups and have to be interoperable. -policy
> doesn't.
> 
> There is only one "dpkg", there is only one "apt", there is only one
> "Debian", and the point of -policy is to make all of these more effective,
> not to help random people with nothing better to do implement clones.
> 
> If we were doing the latter (and you and Manoj seem to want to wrt "dpkg"
> for no reason I can fathom), then must/should would be useful. But
> we're not. If people want to clone dpkg (or finish of libapt-inst so
> it can actually install packages; or implement Herring (if anyone even
> *remembers* it...)) then more power to them. If someone does do this,
> then it might turn out that there are some incompatibilities that need to
> be handled specially by packages, and we'll probably add these to policy
> when we find them.

Who's talking about dpkg here?  Policy covers far more than that.  For
example, when talking about shared and static libraries, there may be
exceptional cases where both the shared library and the development
parts (headers and static library) live in the same package.  Then one
would say something like "Source packages providing shared libraries
SHOULD produce a binary package containing the shared library and
another binary package containing the development files (headers and
statically compiled library).  The shared library MUST be compiled
with the -fPIC option and the static library MUST NOT be compiled with
this option.  ..."  (Please don't correct me on details here -- I
haven't checked them up and that's not the point.)

So here, the "SHOULD" means that it must behave in this way unless
there are exceptional circumstances, and the "MUST" means that there
are no exceptions.  I may be wrong in the details of this specific
case, but this is the way I am thinking.

   Julian

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

      Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
              website: http://www.maths.qmul.ac.uk/~jdg/
   Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/
     Visit http://www.thehungersite.com/ to help feed the hungry


-- 
To UNSUBSCRIBE, email to debian-project-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: