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

Re: a nitpicky reading of policy

Branden Robinson <branden@ecn.purdue.edu> writes:

> On Thu, Dec 02, 1999 at 03:41:34PM -0800, Joey Hess wrote:
> > I read through the policy document today, trying to nitpick and find things
> > that have changed in current practice. Here's what I found:
> >
> > * The policy manual uses the term "section" to refer to main, non-us,
> >   non-free, and contrib. This overloads the term since we typically call
> >   games, libs, docs, etc, sections. Instead, it calls those things
> >   subsections. It also uses the term inconsitently:
> [...]
> >   I think this deserves to be cleaned up, but I don't really know what to
> >   call main, contrib, and non-free. Distributions, maybe?
> We'll, since we are adamant that the Debian distribution consists
> officially only of "main", this might be a bad idea.
> "Category", maybe?

"Category" sounds a bit as if it was refering to the function of the
packages. I'd suggest "area". With "distribution" I'd connected those
thingies like "slink" or "bo".

>    [policy says]
>    Do not create two versions (one with X support and one without) of your
>    package.
> Furthermore, lots of folks scream bloody murder about xlib6g and
> xfree86-common being standard, which makes their installation very likely
> on systems that don't plan to run X servers or clients.
> So, I propose the following compromise:
>   * Downgrade xfree86-common and xlib6g from standard to optional; AND
>   * Modify section 5.8 to say that creating X and non-X versions of a
>     package is permissible *ONLY* if the non-X version qualifies for
>     standard priority.  The X-dependent component can have optional or
>     extra priority.

I think this is a good idea (as long as not too many extra packages
pop up because of this.)
> On a completely different subject, I'm not so sure that TeX and LaTeX
> should really be standard. [reasons snipped]

I agree.

> > * This seems self-contradictory. Are you supposed to remove the created
> >   directories or not?
> >
> >     However, the package should create empty directories below
> >     `/usr/local' so that the system administrator knows where to place
> >     site-specific files.  These directories should be removed on package
> >     removal if they are empty.
> >
> >     Note, that this applies only to directories _below_ `/usr/local', not
> >     _in_ `/usr/local'.  The directory `/usr/local' itself may only contain
> >     the sub-directories listed in FHS, section 4.6.  However, you may
> >     create directories below them as you wish.  You may not remove any of
> >     the directories listed in 4.6, even if you created them.

The important point is "in 4.6", dirs like "/usr/local/share" are
meant. But I don't see how a package could have created one of those,
they should have been created at install time from the "base" tar.

> > * "Any scripts which create files in world-writable directories (e.g., in
> >   `/tmp') have to use a mechanism which will fail if a file with the
> >   same name already exists." I can write code that complies with this and is
> >   still a serious security problem -- the problem is that this sentance
> >   encourages the naive to write something like:
> >   	if [ ! -e /tmp/foo ]; then
> >        		echo "goodbye, /etc/passwd" >/tmp/foo
> > 	fi
> >   Which is vunerable to a race. I think it's be better to require that
> >   it use a "mechanism which will atomically fail ..."
> I agree, but an example of how to do this should be included.  Many newbie
> developers may not know what "atomic" means in an OS context.

Yes, would be very nice to have a pointer here explaining this for C,
sh and perl. For example I do know what is meant, but I still would
look this up somewhere to avoid errors.


Reply to: