g of policy as well? I find people wanting lintian to
> > not
>
> debian-policy (3.5.7.0) unstable; urgency=low
>
> [...]
>
> * Removed the /usr/doc/ symlink clause. closes: Bug#47298,
> Bug#69311
>
excellent.
Now as soon as I get the perl errors to go away I can release this thing. (-:
5.7.0) unstable; urgency=low
[...]
* Removed the /usr/doc/ symlink clause. closes: Bug#47298, Bug#69311
-- Manoj Srivastava <[EMAIL PROTECTED]> Sat, 31 Aug 2002 02:18:02 -0500
--
Martin Michlmayr
[EMAIL PROTECTED]
I am aware that joeyh removed the code from debhelper to support the links and
the discussion seemed to indicate that we felt the compatibility links were
no longer required.
Is this the standing of policy as well? I find people wanting lintian to not
report the warning on their package howeve
PROTECTED]
Subject: Making /usr/doc/XXX symbolic link to ../share/doc/XXX is BAD idea
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 8bit
Package: libcgi-perl
Version: 2.76-13
Package: swig-doc
Version: 1.1.p5-2
(maybe others)
Due to lack of space on the main partition, I
OTECTED]>; Thu, 17 Aug 2000 12:16:34 +0200
Date: Thu, 17 Aug 2000 12:16:34 +0200 (CEST)
From: Santiago Vila <[EMAIL PROTECTED]>
To: Debian Bugs <[EMAIL PROTECTED]>
Subject: [PROPOSAL] Finishing the /usr/doc -> /usr/share/doc transition.
Message-ID: <[EMAIL PROTECTED]>
X-Debbu
Hi,
On Mon, Aug 19, 2002 at 02:39:00PM -0400, Joey Hess wrote:
> Of course policy still says we must. I don't know when we want to change
> that; now or when a lot of packages have stopped including it, or what.
because i hate not having some static place where to look how
things should be done,
On Mon, 19 Aug 2002, Andrew Suffield wrote:
> in /usr/doc/package. To realize a
> smooth migration to
> /usr/share/doc/package, each package
> + added a symlink /usr/doc/package
> + that pointed to the new location of its documentation in
On Mon, Aug 19, 2002 at 02:39:00PM -0400, Joey Hess wrote:
> Henrique de Moraes Holschuh wrote:
> > On Mon, 19 Aug 2002, Oliver Elphick wrote:
> > > Are we still supposed to maintain the /usr/share/doc/x -> /usr/doc/x
> > > link for uploads to sarge?
> >
>
On Mon, 19 Aug 2002, Joey Hess wrote:
> Of course policy still says we must. I don't know when we want to change
> that; now or when a lot of packages have stopped including it, or what.
Well, if we simply change policy not to say anything, then including it is
not against policy.
Later we forbid
Henrique de Moraes Holschuh wrote:
> On Mon, 19 Aug 2002, Oliver Elphick wrote:
> > Are we still supposed to maintain the /usr/share/doc/x -> /usr/doc/x
> > link for uploads to sarge?
>
> No.
Of course policy still says we must. I don't know when we want to chan
On Mon, 19 Aug 2002, Oliver Elphick wrote:
> Are we still supposed to maintain the /usr/share/doc/x -> /usr/doc/x
> link for uploads to sarge?
No.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of R
Are we still supposed to maintain the /usr/share/doc/x -> /usr/doc/x
link for uploads to sarge?
--
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight, UK
http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 6
On Sat, Jul 20, 2002 at 09:10:34PM -0500, Adam Heath wrote:
> > (What about /usr/info <-> /usr/share/info ?)
>
> /usr/info/dir was just recently moved, with dpkg 1.10. That file is now a
> symlink to /usr/share/info/dir. Once all files are moved from
> /usr/info(there's a few left), and all info
Chris Lawrence wrote:
> On Jul 20, Joey Hess wrote:
> > So would anyone murder me if the code in debhelper to make postinst
> > scripts manage /usr/doc links just went missing? This would of course
> > cause the link to go away when packages were upgraded to versions b
off if some newcomers to this issue want to go back and read
> over the several thousand old messages about this transition to
> familiarize themselves with the TC decision.)
IMO we could offer it (/usr/doc as a symlink) as a base-config
question at the lowest priority, with a default of no
> > [EMAIL PROTECTED]:~>doc=/usr/share/doc
> > [EMAIL PROTECTED]:~>less ~doc/debian-policy/policy.txt.gz
>
> Nice. however how is this different from setting doc to /usr/share/doc
> and then using $doc to refer to it? The only thing I can see is that it
> get's expanded if I use tab completion, bu
On Mon, Jul 22, 2002 at 12:02:56PM +0200, Santiago Vila wrote:
> retitle 69311 [PROPOSAL] Symlinks in /usr/doc not mandatory anymore.
> thanks
> [ I naively proposed something like this after the release of potato,
> but it was not the right time... ].
> Proposed patch to
Colin Watson wrote:
> Seconded. I believe this is consistent with the original proposal
> approved by the TC.
Likewise seconded.
--
see shy jo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Mon, 22 Jul 2002, Santiago Vila wrote:
> retitle 69311 [PROPOSAL] Symlinks in /usr/doc not mandatory anymore.
> thanks
>
> [ I naively proposed something like this after the release of potato,
> but it was not the right time... ].
>
> Proposed patch to current po
-- debian-policy-3.5.6.1.orig/policy.sgmlThu Mar 14 19:17:48 2002
> +++ debian-policy-3.5.6.1/policy.sgml Mon Jul 22 11:19:58 2002
> @@ -7383,48 +7383,6 @@
>
>
>
> -
> - Accessing the documentation
> -
> -
> - Former Debian releases pla
1:19:58 2002
> @@ -7383,48 +7383,6 @@
>
>
>
> -
> - Accessing the documentation
> -
> -
> - Former Debian releases placed all additional documentation
> - in /usr/doc/package. To realize a
> - smooth migration to
> - /us
-policy-3.5.6.1/policy.sgml Mon Jul 22 11:19:58 2002
@@ -7383,48 +7383,6 @@
-
- Accessing the documentation
-
-
- Former Debian releases placed all additional documentation
- in /usr/doc/package. To realize a
- smooth migration to
- /usr
Santiago Vila (2002-07-22 12:02:56 +0200) :
[...]
> I'm looking for seconds for this proposal, which is *just* to stop
> requiring symlinks.
Seconded.
Roland.
--
Roland Mas
ar c t e l l ièu ai ia mi.
-- Signatures à collectionner, série n°1, partie 2/3.
pgpW2LKqAfnY
Processing commands for [EMAIL PROTECTED]:
> retitle 69311 [PROPOSAL] Symlinks in /usr/doc not mandatory anymore.
Bug#69311: [PROPOSAL] Finishing the /usr/doc -> /usr/share/doc transition.
Changed Bug title.
> thanks
Stopping processing here.
Please contact me if you need assistance
retitle 69311 [PROPOSAL] Symlinks in /usr/doc not mandatory anymore.
thanks
[ I naively proposed something like this after the release of potato,
but it was not the right time... ].
Proposed patch to current policy:
diff -r -u debian-policy-3.5.6.1.orig/policy.sgml
debian-policy-3.5.6.1
pose Santiago'll also be uploading a base-files without
> /usr/doc, if he hasn't already.
I did that in base-files_2.2.15 but restored it in base-files_3.0.0
because, according to Manoj, it was completely acceptable for a
package to blindly assume that /usr/doc exists when creating o
On Mon, 22 Jul 2002, Joey Hess wrote:
> Santiago Vila wrote:
> > We have never released "suddenly" a new stable distribution, and I don't
> > think sarge will be an exception. People have the complete lifetime of
> > woody to change habits, if they are very use
erhaps?
Do we really have to enforce the FHS on users' systems? If we remove all
the symlinks in /usr/doc (which should be all that is in there from
up-to-date Debian packages, right?), check if /usr/doc is empty, and
remove it if so, shouldn't that be enough?
There's no reason even
Anthony Towns wrote:
> Anyway, I'd thought we were considering removing all the symlinks in one
> shot rather than waiting for every package to be updated. Indeed, Manoj's
> message to the tech ctte said:
Yes, we can do that. Things to watch out for:
- old aliened packages
Santiago Vila wrote:
> We have never released "suddenly" a new stable distribution, and I don't
> think sarge will be an exception. People have the complete lifetime of
> woody to change habits, if they are very used to do "cd /usr/doc".
zsh-folk may find t
On Sun, Jul 21, 2002 at 05:12:52PM -0400, Joey Hess wrote:
> If noone who is faimilar with the history and aims of this transition
> has any objects, the I will upload the new debhelper tomorrow, I guess.
Sounds good. I suppose Santiago'll also be uploading a base-files without
/usr
Adam Heath wrote:
> We first need a script to remove /usr/doc itself, and make it a symlink to
> share/doc, before you start removing the debhelper code.
>
> Otherwise, suddenly /usr/doc becomes empty, and those that access
> documentation thru that location suddenly can't.
We
Adam Heath wrote:
> Er, this symlink was just recently made. Which means all existing browsers
> still use /usr/info/dir.
I don't know about the others, but the standard info reader (from the
texinfo package) supports the dir file being either in /usr/info or
/usr/share/info. It uses whichever on
ion
is complete, /usr/doc is no more, and /usr/share/doc is the place to look
might be worth including when the time comes... if we get it done. :-)
Bdale
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Sun, 21 Jul 2002, Joey Hess wrote:
> No, I want to see no /usr/doc. If you want to make some symlink be my guest,
> but /usr/doc is a FHS violation.
So? We have other FHS violations. We don't follow it strictly.
> The transition plan, which you have had 3 years to comment
Adam Heath wrote:
> That was years ago. And, now that we are at this point, we should do
> it right, and not following the recommendation given by some group of
> people long ago that didn't forsee this problem.
That is false. We forsaw this problem 3 years ago, discussed this very
issue, came up
Adam Heath wrote:
> So, you'd rather see a half-empty /usr/doc, which is not very useful, then to
> have a script, that links /usr/doc to share/doc, and would not cause any loss
> of functionality?
> /usr/doc is much shorter to type, than /usr/share/doc.
No, I want to see no
s years ago. And, now that we are at this point, we should do it
right, and not following the recommendation given by some group of people long
ago that didn't forsee this problem.
> Yes, a half-empty /usr/doc is the next stage of the plan, just like a
> half-empty /usr/share/doc was
On Sun, Jul 21, 2002 at 03:32:46PM -0500, Adam Heath wrote:
> So, you'd rather see a half-empty /usr/doc, which is not very
> useful, then to have a script, that links /usr/doc to share/doc, and
> would not cause any loss of functionality?
Oh, no no no! We're not reopenin
On Sun, 21 Jul 2002, Joey Hess wrote:
> Adam Heath wrote:
> > Otherwise, suddenly /usr/doc becomes empty, and those that access
> > documentation thru that location suddenly can't.
>
> Um, those people have had a major release of debian which documents that
> the do
Adam Heath wrote:
> Otherwise, suddenly /usr/doc becomes empty, and those that access
> documentation thru that location suddenly can't.
Um, those people have had a major release of debian which documents that
the docs are in /usr/share/doc, and several years to become prepared for
On Sat, 20 Jul 2002, Joey Hess wrote:
> So would anyone murder me if the code in debhelper to make postinst
> scripts manage /usr/doc links just went missing? This would of course
> cause the link to go away when packages were upgraded to versions built
> with the new debhelper. Si
On Sun, 21 Jul 2002, Santiago Vila wrote:
> Adam Heath wrote:
> > /usr/info/dir was just recently moved, with dpkg 1.10. That file is now a
> > symlink to /usr/share/info/dir.
>
> We should not need /usr/info/dir as a symlink. install-info works ok
> without the symlink, the standard info browser
Joey Hess wrote:
> So would anyone murder me if the code in debhelper to make postinst
> scripts manage /usr/doc links just went missing?
There would be reasons to murder you if you *don't* do that change ;-)
Adam Heath wrote:
> /usr/info/dir was just recently moved, with dpkg 1.
On Sat, Jul 20, 2002 at 09:09:26PM -0500, Adam Heath wrote:
> On Sat, 20 Jul 2002, Joey Hess wrote:
> > So would anyone murder me if the code in debhelper to make postinst
> > scripts manage /usr/doc links just went missing? This would of course
> > cause the link to go aw
On Sat, 20 Jul 2002, Marco d'Itri wrote:
> (What about /usr/info <-> /usr/share/info ?)
/usr/info/dir was just recently moved, with dpkg 1.10. That file is now a
symlink to /usr/share/info/dir. Once all files are moved from
/usr/info(there's a few left), and all info browsers read from
/usr/sha
On Sat, 20 Jul 2002, Joey Hess wrote:
> So would anyone murder me if the code in debhelper to make postinst
> scripts manage /usr/doc links just went missing? This would of course
> cause the link to go away when packages were upgraded to versions built
> with the new debhelper. Si
On Sat, Jul 20, 2002 at 12:56:10PM -0400, Joey Hess wrote:
> So would anyone murder me if the code in debhelper to make postinst
> scripts manage /usr/doc links just went missing?
We really should make the corresponding change to policy too, but I
won't complain if debhelper leads pol
On Jul 20, Joey Hess wrote:
> So would anyone murder me if the code in debhelper to make postinst
> scripts manage /usr/doc links just went missing? This would of course
> cause the link to go away when packages were upgraded to versions built
> with the new debhelper. Since we'
On Jul 20, Joey Hess <[EMAIL PROTECTED]> wrote:
>So would anyone murder me if the code in debhelper to make postinst
>scripts manage /usr/doc links just went missing? This would of course
Please do.
(What about /usr/info <-> /usr/share/info ?)
--
ciao,
Marco
--
To UNS
Joey Hess <[EMAIL PROTECTED]> writes:
> So would anyone murder me if the code in debhelper to make postinst
> scripts manage /usr/doc links just went missing? This would of course
> cause the link to go away when packages were upgraded to versions built
> with the new debhelp
Joey Hess (2002-07-20 12:56:10 -0400) :
> So would anyone murder me if the code in debhelper to make postinst
> scripts manage /usr/doc links just went missing?
I wouldn't. And this is a second.
Roland.
--
Roland Mas
Un clavier azerty en vaut deux.
pgpTKbZSRcLyw.pgp
Descr
On Sat, 20 Jul 2002, Joey Hess wrote:
> So would anyone murder me if the code in debhelper to make postinst
> scripts manage /usr/doc links just went missing? This would of course
> cause the link to go away when packages were upgraded to versions built
> with the new debhelper. Si
So would anyone murder me if the code in debhelper to make postinst
scripts manage /usr/doc links just went missing? This would of course
cause the link to go away when packages were upgraded to versions built
with the new debhelper. Since we'll be recompiling lots of stuff anyway
in sarge fo
Any packages uploaded to unstable now are (presumably) intended
for woody+1. Is it appropriate to omit the /usr/doc/
symlinks in packages being uploaded currently, or should this wait for
a post-woody release of debian-policy?
Bob
--
_
|_) _ |_ Robert D. Hilliard <[EM
]
Subject: Next stage in usr/doc -> usr/share/doc transition
Message-ID: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Organisation: Lacking
X-PGP: http://azure.humbug.org.au/~aj/aj_key.asc
From: Anthony T
d error messages (sorta common)?
>
> Programmatically, mainly.
Well then I don't have any real objections. Aside from the web servers,
and possibly document indexing systems like dhelp and so on, I suppose
the number of programs that hard code /usr/doc is pretty rare. And a
sizable chunk of
ian, so if this is way off base then
> ignore me)
Further to this:
stephen:~$ cat wrongmanpages
undocumented.7 (not really apposite as /usr/doc *is* a valid
place for undocumented.7 to point to, /usr/share/doc
should be listed first maybe, or even listed at all?)
liloconfig.8
k
ht way to go
about generating a list of affected packages? (I don't really have any
idea of the internals of lintian, so if this is way off base then
ignore me)
>
> It also has the problem of the web server policy still requiring that
> "HTML documents for a package are stored in
f grepping.
> It also has the problem of the web server policy still requiring that
> "HTML documents for a package are stored in `/usr/share/doc/'
> but should be accessed via symlinks as `/usr/doc/'" (So at the
> minimum, your policy patch needs to deal with that
Anthony Towns wrote:
> I think the most efficient way of handling usr/doc for woody will be to
> have everything reference /usr/share/doc, and require all packages to
> put their files in /usr/share/doc, and to make symlinks in /usr/doc. The
> latter is mainly for partial upgrades.
>
uments for a package are stored in
> -/usr/share/doc/package but should
> -be accessed via symlinks as
> -/usr/doc/package
> -
> - for backward compatibility
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Monday 25 June 2001 11:42 am, Anthony Towns wrote:
> Package: debian-policy
> Version: 3.5.5.0
>
> I think the most efficient way of handling usr/doc for woody will be
> to have everything reference /usr/share/doc, and require all pa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Anthony Towns wrote:
>I think the most efficient way of handling usr/doc for woody will be to
>have everything reference /usr/share/doc, and require all packages to
>put their files in /usr/share/doc, and to make symlinks in /usr/doc. The
&
Package: debian-policy
Version: 3.5.5.0
I think the most efficient way of handling usr/doc for woody will be to
have everything reference /usr/share/doc, and require all packages to
put their files in /usr/share/doc, and to make symlinks in /usr/doc. The
latter is mainly for partial upgrades.
To
Your message dated Thu, 15 Mar 2001 23:35:23 +
with message-id <[EMAIL PROTECTED]>
and subject line Bug#89807: packaging-manual still refers to /usr/doc
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is n
Package: packaging-manual
Version: 3.2.1.0
Severity: normal
$ zgrep usr/doc /usr/doc/packaging-manual/packaging.text.gz
`/usr/doc/copyright/GPL' in the Debian GNU/Linux distribution or on
dpkg --fsys-tarfile .deb | tar xof usr/doc/<\*>copyright | less
file fro
700
Received: from xtifr by thrak with local (Exim 2.11 #1 (Debian))
id 11CA34-0003Gd-00; Wed, 4 Aug 1999 16:02:14 -0700
From: Chris Waters <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [PROPOSED} delay the /usr/doc transition till after potato
Mime-Version: 1.0 (generated by tm-edit 7
PROTECTED]; Tue, 6 Jul 1999 10:56:31 +0200 (CEST)
Message-Id: <[EMAIL PROTECTED]>
Date: Tue, 6 Jul 1999 10:56:31 +0200 (CEST)
From: <[EMAIL PROTECTED]>
Subject: debian-policy: Section 5.8 refers to /usr/doc/package
To: [EMAIL PROTECTED]
X-Mailer: bug 3.2.2
Package: debian-policy
Ver
02:27:02 +0200
Date: Sun, 4 Jul 1999 02:27:01 +0200
From: Roland Rosenfeld <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: /usr/share/doc vs. /usr/doc
Message-ID: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/0.96.3i
Sender: [EMAIL P
Anthony Towns wrote:
> I think though, probably because policy wasn't very clear about this,
> that packages in potato already look in /usr/share/doc for documentation,
> so they're already broken, and this may no longer really matter.
At least apache seems to still use /usr/d
Santiago Vila wrote:
> Please note that not every dependency or conflict is explicit. You
> can't read new manpages using an old enough man-db package, unless you
> make a little bit of tweaking in the configuration file, and we don't
> speak about "breakage" because of the need of this tweaking.
can change the recommendation in policy something like:
Former Debian releases placed all additional documentation in
`/usr/doc/'. To realize a smooth migration to
`/usr/share/doc/', each package must maintain a symlink
`/usr/doc/' that points to the new location of its
-
like current potato, which is a mix of
FHS and non-FHS. "If you move things around, dpkg will get very upset"
it was said a lot of times.
Well, with the dpkg in potato this is no longer true, and for most
(if not all) packages still using /usr/doc it is currently possible to
do this:
cd
nsively during
the development phase of Woody. Introducing breakage would slow down
the release of Woody, and would interfere with proper testing of the
rest of the system.]
Also, introducing dependencies to manage the /usr/doc/ transition would
add a whole new suite of problems. If you care to
dification of the original plan, by letting the
two transitions which still have to be done to overlap:
1. Packages use /usr/share/doc. This transition is 79% complete. We
expect it to be complete by the time woody is released.
2. Packages do not create any symlinks in /usr/doc.
This transit
>>"Santiago" == Santiago Vila <[EMAIL PROTECTED]> writes:
Santiago> 930 packages when looking for usr/doc and
Santiago> 3565/(3565+930) = 79% of packages already use /usr/share/doc.
Santiago> This is exactly where I think there is a major flaw in the
Santi
On 22 Aug 2000, Manoj Srivastava wrote:
> I see woody release and making not having docs in
> /usr/share/doc/ as an RC bug as being the stick that shall
> ensuer compliance (I currently have 170 packages on *my* machine that
> are not compliant).
> __> zgrep ^usr/do
>>"Santiago" == Santiago Vila <[EMAIL PROTECTED]> writes:
Santiago> On 20 Aug 2000, Manoj Srivastava wrote:
>> What is wrong with the plan currently in place?
Santiago> It will slow down the goal of FHS compliance (inclusing an empty
Santiago> /usr/do
On Mon, Aug 21, 2000 at 12:20:08PM -0700, Chris Waters wrote:
> Things have *not* gone as planned so far. So, saying "stick with the
> plan, stick with the plan" seems a bit myopic. We're already not
> sticking with the plan, which involved releasing Potato in time for
> Christmas '99, IIRC.
>
>
f actual dates in the decision point to that being
the case. Not to mention the whole symlink thing.
If we started removing /usr/doc links right now, what would happen?
Apache's http://localhost/doc would start having holes in it for
one. Yes, it still uses /usr/doc. I think dhelp would brea
(Side comment: Joey, setting mail-followup-to both the bug number and
the policy list, when the bug is a bug against policy, is really not a
great plan.)
On Sun, Aug 20, 2000 at 03:23:39PM -0700, Joey Hess wrote:
> Have you read http://lists.debian.org/debian-ctte-9909/msg00023.html and
> http://
On 20 Aug 2000, Manoj Srivastava wrote:
> What is wrong with the plan currently in place?
It will slow down the goal of FHS compliance (inclusing an empty
/usr/doc) even more.
I thought the plan was that for each given Debian distribution, we
should be telling our users to look for docs i
Hi,
I think I must object to this proposal. I think nothing good
can come out of this hastening of the planned transition; espescially
since no good reaso is given as to why we must sccelrate the
transition process. What is wrong with the plan currently in place?
manoj
--
You
Santiago Vila wrote:
> Now that potato has been released, I propose that we start deprecating
> the /usr/doc compatibility symlinks, at the same time we make
> using /usr/share/doc a nearly-release-goal for woody.
Have you read http://lists.debian.org/debian-ctte-9909/msg00023.html
On Sun, Aug 20, 2000 at 08:56:29PM +0200, Adrian Bunk wrote:
[re: getting rid of symlinks in /usr/doc]
> That means it's already a bug if a package doesn't remove this link in
> it's prerm.
Ah, so it is. Good point. In that case, I withdraw my objection and
second Santiag
On Sun, Aug 20, 2000 at 11:31:32AM -0700, Chris Waters wrote:
> On Thu, Aug 17, 2000 at 12:16:34PM +0200, Santiago Vila wrote:
> > Now that potato has been released, I propose that we start deprecating
> > the /usr/doc compatibility symlinks, at the same time we make
> > u
On Sun, 20 Aug 2000, Chris Waters wrote:
> I think an addendum is needed to this proposal -- if any package *has*
> had symlinks in /usr/doc, then it needs to clean them up in its
> install scripts, now, and possibly forever.
>
> This is one of the reasons I objected to the symlin
On Thu, Aug 17, 2000 at 12:16:34PM +0200, Santiago Vila wrote:
> Now that potato has been released, I propose that we start deprecating
> the /usr/doc compatibility symlinks, at the same time we make
> using /usr/share/doc a nearly-release-goal for woody.
I think an addendum is neede
On Thu, Aug 17, 2000 at 12:16:34PM +0200, Santiago Vila wrote:
>
> Now that potato has been released, I propose that we start deprecating
> the /usr/doc compatibility symlinks, at the same time we make
> using /usr/share/doc a nearly-release-goal for woody.
[...]
> I'm loo
On Aug 17, Santiago Vila <[EMAIL PROTECTED]> wrote:
>Now that potato has been released, I propose that we start deprecating
>the /usr/doc compatibility symlinks, at the same time we make
>using /usr/share/doc a nearly-release-goal for woody.
Seconded.
--
ciao,
Marco
Package: debian-policy
Severity: wishlist
Now that potato has been released, I propose that we start deprecating
the /usr/doc compatibility symlinks, at the same time we make
using /usr/share/doc a nearly-release-goal for woody.
The idea is, assuming this proposal is accepted:
* We modify
Hi,
Though trying to provide the equivalent of /etc/hosts.{allow,deny}
for services not controlled by tcp wrappers and inetd is laudable,
this specific case could easily be addressed by a simple change in
the default access.conf (this is apache specific, I am sure other
servers have eq
e> from using the web to browse the docs from all the machines
Steve> but one.
Umm. Not quite. If the other machines are not running a web
server, you can't access /usr/doc from them. Perhaps you meant, if
they were all running web servers, and exporting /usr/doc, you cou
proposal, but I think this is better than just
> referring to /usr/doc.
>
> I think this is more of a "show me the code" type of situation.
I need to think through the concepts a bit more before I try tackling
code. [A proof of concept doesn't seem hard -- what seems hard is a
stion
> or three, so that people can choose whether they want this level of detail
> at config time, and then leave the rest up to package implementation.
This sounds really interesting. I think it needs some work before it
becomes a policy proposal, but I think this is better tha
>>>>> "Martin" == Martin Schulze <[EMAIL PROTECTED]> writes:
Martin> Julian Gilbey wrote:
>> Here's an issue. About two years ago there was a proposal that
>> the default httpd setup should not allow /usr/doc to be
>>
Julian Gilbey wrote:
> Here's an issue. About two years ago there was a proposal that the
> default httpd setup should not allow /usr/doc to be remotely
> accessible, as it's a huge security risk. (Yes, we're talking about a
> small amount of "security through ob
On Tue, Jun 20, 2000 at 02:35:45PM +0200, Petr Cech wrote:
> On Tue, Jun 20, 2000 at 09:58:01AM +0100 , Julian Gilbey wrote:
> > Here's an issue. About two years ago there was a proposal that the
> > default httpd setup should not allow /usr/doc to be remotely
> >
On Tue, Jun 20, 2000 at 09:13:47AM -0400, Steve Robbins wrote:
> > Here's an issue. About two years ago there was a proposal that the
> > default httpd setup should not allow /usr/doc to be remotely
> > accessible, as it's a huge security risk. (Yes, we're ta
1 - 100 of 469 matches
Mail list logo
