On undocumented(7):
As I remember it from Ol Times (at the time I was one of the mandators that
debian should include manual *sources* instead of catmans :) the purpose of
undocumented(7) was to signal that a package had no documentation *at all*.
If a package had other documentation, say in info
Ian proposes the following wrt /usr/doc vs /usr/share/doc:
> * Any dpkg bug in this area be fixed. If I can figure out what people
> claim the bug is I'll fix it. (I won't build an NMU, but we seem to
> have no shortage of people willing to do dpkg NMUs.)
The bug was explained to me in the seco
Antti-Juhani proposes:
> This deadline is almost at hand. I've produced a final draft of the
> amendment for your review. Consider it frozen: i will not make any
> substantial changes to it anymore - only simple thinkos and typos will
> be corrected. I hope we can get a consensus to back this a
Michael Stone on my proposal (available from
http://www.ens-lyon.fr/~krisrose/ftp/Debian/usr-doc-proposal.txt>):
> Well, the real reason is that you're trying to rearrange 110M that might
> be located on a filesystem other than the destination filesystem. [...]
You are right. At the moment the s
Dear Joseph Carter,
I'm sorry to shout but please read what I write.
> All right dammit, here we go... built a package crap 1.0-1, here is the
> listing:
>...
> /usr/lib/crap/olddir
>...
> Do you believe us yet? What more proof do you possibly need?
I am happy to tell you that we agree comple
I proposed:
>> 1. REQUIRE that /usr/doc is a symlink to the FHS directory /usr/share/doc.
Joseph Carter replied:
> Breaks dpkg. Propose it all you want, but it's not going to happen if you
> don't provide the patch for dpkg to follow symlinks. Either that or all
> packages must be upgraded and
Thanks for reopening the debate, Chris.
I am (still) following it and I (still :) do not understand what is wrong
with the following'
debian-policy [PROPOSAL]: /usr/doc -> /usr/share/doc should be a symlink
I propose that the "transition" of /usr/doc to /usr/share/doc be done with
the following
Martin Bialasinski proposes:
> I am working on converting the tasks and profiles from the base
> installation into ordinary packages.
I've always wanted this, thanks for the investment :)
> This will make the thing easier to manage, and offer these packages
> also for later installation.
Indeed
Dear all,
Excuse me for asking a really silly question but I fear that we are
overlooking the obvious in our enthusiasm for the complicated.
I tried to do the following on one of my slink systems:
# cd /usr/
# ls share/doc
ls: share/doc: No such file or directory
# mv doc share/doc
# l
Dear Branden,
> I see so reason /usr/X11R6 has to continue to exist at all.
>
> /usr/{bin,include,lib}/X11/ is the canonical path with which to reach X
> stuff.
>
> Therefore,
> /usr/bin/X11 would be a symlink to /usr/bin (X11 -> .)
> /usr/include/X11 would become a regular directory
> /us
Branden writes:
> Maybe. I've long been mulling over the thought of moving X into /usr.
Hear, hear! I wanted this to happen in the fsstnd work that happened
during debian 0.93 but (as you vigilantly point out :) the disk size
problem at the time was to big a hurdle for most.
> Like I said befo
-BEGIN PGP SIGNED MESSAGE-
- --J6FFpFs/nX
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Marcus Brinkmann writes:
> We just would need a setup where those interests don't collide. There is the
> real problem: People who feel strong about Free Software (mora
Marcus Brinkmann writes:
> Yes, there will be a certain degree of compatibility, even binary
> compatibility. But, and this is a big but, we still need our own kernel,
> translators, glibc, and some other low level stuff (network, etc).
Just to complicate things: we really should make it possible
Ian proposes:
> It's clear that Optional is far too large. Although we nominally say
> that packages for which you need to have a special requirement before
> you want to install them should go in Extra, this rule hasn't been
> well enforced, and is in any case contentious.
I agree...in fact I'd
Milan Zamazal writes:
> No, requiring knowing dozens of languages would be *real* discrimination.
Indeed, also. But carefully *not* requiring anything is much better since
it puts the responsibility where it belongs: with the developer who
uploaded the package (to main). We do *not* want debian
I wrote:
>> Requiring this formally will make it impossible for many commercials to
>> contribute (since you cannot reasonably be required to mention the
>> competition).
Mark W. Eichin replied:
> Umm, I don't see how that follows, actually. Granted, we're trying to
> avoid that the *other* dir
Guy Maor asks:
> There's currently a package in Incoming, sympa, with a copyright file
> written in French. This raises a host of potential problems, and may
> require some policy changes.
IMHO we should simply put the French copyright file in the distribution...
> Should an English translation
Raul Miller:
> [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > If all packages that "Suggests:" hugs should explicitly name
> > "non-free/hugs" then they will have to change when hugs moves.
>
> Oh, I thought you were talking about "Enhances:".
>
> Yes, I agree, Suggests: of the form "non-free/
I wrote:
> I don't see the need for this. On the contrary it may create problems as
> packages *move* from non-free to free (like KDE will, maybe, have done)
> and that would create inconsistencies which we shouls avoid at all costs!
Raul Miller asks:
> What inconsistencies?
I like to believe t
[Moved to debian-policy from debian-vote...]
Craig Sanders proposes on the don't-suggest-non-free issue:
> what do you think of this more moderate compromise position:
>
> 1. by default, don't display broken Suggests: but allow the user to
> toggle this option.
>
> 2. have policy stro
Fabrizio Polacco writes:
> We should stop considering that things packaged in .deb are "delivered
> by Debian". Also other people can (should) start packaging their own
> stuff in .deb , and providing a clear policy on how to do (installing
> under /opt) would be a service for the community.
I di
Buddha Buck asks:
> Is there any particular reason (besides history and inertia) that
> non-free and contrip packages aren't installed into /opt?
Yes: it was discussed long & hard several years back. The conclusion was
that the only truly scaleable solution was to use a completely flat
structur
Mark W. Eichin writes:
> In a thread on -private about pdf viewers, it was noticed that people
> were sometimes unaware of free alternatives to non-dfsg software; the
> particular example was acroread (with gv and xpdf as free replacements.)
>
> This suggests an enhancement: non-free packages sho
Dear Ben,
I think putting the md5sums in the package sounds like a good thing --
should dpkg-buildpackage do it?
> Anyone have "Debian on a super-slow machine" stories they care to
> share? ;) My slowest was a 386 DX/40.
Sure: all through '93 my debian developer's system was a 386 DX/25 with a
2
I wrote:
>>> Finally, it would be very nice if the hierarchy was under
>>> /usr/share/texmf rather than /usr/lib/texmf since the texmf hierarchy
>>> was designed to be sharable this way ... and it will also make it much
>>> easier to make "installers" for things such as the TeX Live 3 CD-ROM
>>> we
25 matches
Mail list logo
