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.
Falk
Reply to: