Manoj Srivastava wrote:
> Hmm. Could you set up the symlink, install a package that
> installs stuff in /usr/doc; install a package that installs stuff in
> /usr/share/doc/; purge both packages. If these work, then we just
> have to worry about the mechanism that does the moving -- can o
Hi,
[I think, since this is a dead proposal, there is not much
point carrying out what has become a nit picking discussion
about the nature of flaws and the meannig of requirements. As
usual, I think we have moved into one of our endless dabates
that lead to
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> The fact that a single probe into the location derived using
> the pacjage name is no longe guaranteed to work is indeed a technical
> fault.
First of all, this hardly the only proposal which could adress that
concern (see other proposals b
On Wed, Jul 21, 1999 at 03:13:55AM +0200, Richard Braakman wrote:
> Manoj Srivastava wrote:
> > For multi binary packages I tend to have separate installation
> > script for each binary package. Is that not the case generally? (I
> > also tend to have the package name in a lot of maintain
> First of all, I should make it clear that in practice, this is
> probably even *less* important than the previous technical objection.
> But it is, still, a *technical* problem, however minor.
>
>
Hi,
>>"Chris" == Chris Waters <[EMAIL PROTECTED]> writes:
Chris> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>> >>"Chris" == Chris Waters <[EMAIL PROTECTED]> writes:
Chris> Which leaves the "user is used to '/usr/doc'" objection, which is a
Chris> *purely* aesthetic objection, not a technica
Hi,
>>"Joey" == Joey Hess <[EMAIL PROTECTED]> writes:
Joey> Manoj Srivastava wrote:
>> dpkg may well have problems with the symlink, so any
>> packages still installing in /usr/doc/ could cause problems
>> with dpkg. Since the move is likely to take a long time, this grand
>> move-in-one-fel
Chris Waters wrote:
> Programs like dwww and dhelp will already have to be modified to look
> in both places, since users may have a mixture of old and new packages
> installed even after we make the transition to policy 4.x.
>
> Which leaves the "user is used to '/usr/doc'" objection, which is a
Manoj Srivastava wrote:
> dpkg may well have problems with the symlink, so any
> packages still installing in /usr/doc/ could cause problems
> with dpkg. Since the move is likely to take a long time, this grand
> move-in-one-fell-swoop is likely to be fraught with problems.
After read
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> >>"Chris" == Chris Waters <[EMAIL PROTECTED]> writes:
> Chris> Which leaves the "user is used to '/usr/doc'" objection, which is a
> Chris> *purely* aesthetic objection, not a technical one
> You are missing the point. It is not that users
Hi,
>>"Steve" == Steve Greenland <[EMAIL PROTECTED]> writes:
Steve> I think I agree with this, the effort and additional cruft is to big
Steve> for the benefit.
Do you formally object to the proposal?
Steve> And it seems to me a that a script that maintained
Steve> /usr/doc/whateve
Hi,
>>"Marcus" == Marcus Brinkmann <[EMAIL PROTECTED]> writes:
Marcus> A little script that creates symlinks in /usr/doc for each
Marcus> directory in /usr/share/doc was already posted, we could
Marcus> advertise it to our users who really want that.
Please propose this as a separate p
Manoj Srivastava writes:
> dpkg may well have problems with the symlink, so any packages still
> installing in /usr/doc/ could cause problems with dpkg.
> Since the move is likely to take a long time, this grand
> move-in-one-fell-swoop is likely to be fraught with problems.
This is a weak argume
Hi,
> Richard> I think the symlink should be absolute, not relative.
> Richard> /usr/doc is a likely directory to be symlinked to somewhere
> Richard> else by the sysadmin (for example, to deal with this
> Richard> transition :-), and the normal reason for using relative
> Richard> links (tha
On 19-Jul-99, 19:41 (CDT), Marcus Brinkmann <[EMAIL PROTECTED]> wrote:
>
> The price is actually higher. Richard already pointed out some corrections
> to your proposal, which add complication.
>
> But the real expense is elsewhere. I wonder why this hasn't come up before,
> but here it is:
>
>
Manoj Srivastava wrote:
> Richard> This seems unnecessarily complex. You do not need to change
> Richard> the directory.
>
> Well, it makes me feel better when creating symbolic links.
Okay, a matter of taste :) I find it hard to read scripts that change
directories, and I also think
Peter S Galbraith wrote:
> Don't use absolute links.
> >From policy version 2.5.0.0:
>
> 4.5. Symbolic links
> ---
>
> In general, symbolic links within a toplevel directory should be
> relative, and symbolic links pointing from one toplevel directory into
> another
Hi,
On Mon, Jul 19, 1999 at 11:23:59PM -0500, Manoj Srivastava wrote:
> >>"Santiago" == Santiago Vila <[EMAIL PROTECTED]> writes:
>
> Santiago> This is a high price to pay, very high.
>
> Adding a stanza to a couple of files too high a price to pay?
The price is actually higher. Richar
Hi,
>>"Chris" == Chris Waters <[EMAIL PROTECTED]> writes:
Chris> Which leaves the "user is used to '/usr/doc'" objection, which is a
Chris> *purely* aesthetic objection, not a technical one
You are missing the point. It is not that users prefer one to
the other, the objection is that t
Hi,
>>"Richard" == Richard Braakman <[EMAIL PROTECTED]> writes:
Richard> That should be postinst and prerm, to stay out of dpkg's
Richard> way. If you remove it only in the postrm, then you will
Richard> break downgrades to pre-FHS versions.
I shall so amend the proposal.
Richard>
Hi,
>>"Kristoffer" == Kristoffer Rose <[EMAIL PROTECTED]> writes:
Kristoffer> Excuse me for asking a really silly question but I fear
Kristoffer> that we are overlooking the obvious in our enthusiasm for
Kristoffer> the complicated.
Enthusiam for the complicated? More like enthusiasm f
Richard Braakman wrote:
> This seems unnecessarily complex. You do not need to change the directory.
> I suggest (using absolute links while I'm at it):
>
>if [ -d /usr/doc ]; then
> if [ ! -e /usr/doc/$package -a -d /us
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
Manoj Srivastava wrote:
> 3. Proposed solution
>
>
> I propose that there be a syymlink from /usr/doc/package =>
> /usr/share/doc/package, managed by the package itself. Since there is
> some concern that the packaging system does not deal well with
> repla
Hi,
>>"Santiago" == Santiago Vila <[EMAIL PROTECTED]> writes:
Santiago> But your proposed solution creates an inmense lot of work
Santiago> for everybody, just to keep compliance with a standard
Santiago> (FSSTND) which is not the one that we should follow. Every
You have a strange def
Hi,
>>"Santiago" == Santiago Vila <[EMAIL PROTECTED]> writes:
Santiago> This is a high price to pay, very high.
Adding a stanza to a couple of files too high a price to pay?
Your solution ignores all the points made in the proposal:
* The transition may take a long tim
-BEGIN PGP SIGNED MESSAGE-
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> PROPOSAL: Easing the transition from `/usr/doc' to `/usr/share/doc'
[...]
> During the transition, we need to provide backwards compatibility,
> firstly for programs ike `dwww', and `dhelp', and also for our users
>
On 19 Jul 1999, Manoj Srivastava wrote:
> >>"Santiago" == Santiago Vila <[EMAIL PROTECTED]> writes:
>
> Santiago> So, the *only* remaining reason for the symlinks is the
> Santiago> users who have gotten used to look under /usr/doc. Well,
> Santiago> they will have to get used to look under /u
Hi,
>>"Santiago" == Santiago Vila <[EMAIL PROTECTED]> writes:
Santiago> Please note that when we switched from
Santiago> /usr/doc/copyright/package to /usr/doc/package/copyright we
Santiago> didn't create any smylinks "for backwards compatibility".
The copyrights are accessed far less
On 17 Jul 1999, Manoj Srivastava wrote:
> * We should not break backwards compatibility during the transition
> period. This is a quality of implementation issue
>
> During the transition, we need to provide backwards
> compatibility, firstly for programs ike
-BEGIN PGP SIGNED MESSAGE-
On 17 Jul 1999, Manoj Srivastava wrote:
> PROPOSAL: Easing the transition from `/usr/doc' to `/usr/share/doc'
> ---
>
> Manoj Srivastava <[EMAIL PROTECTED]>
>
In the interests of seeing a solution to this problem happen soon and
before anymore maintainers take it upon themselves to decide how the
/usr/share/doc migration should happen, I second Manoj's proposal. I
would prefer the symlinks be managed seperately from the package that
needs them, but upon
retitle 40706 [AMENDMENT 17/7/99] /usr/share/doc vs. /usr/doc transition
thanks
PROPOSAL: Easing the transition from `/usr/doc' to `/usr/share/doc'
---
Manoj Srivastava <[EMAIL PROTECTED]>
33 matches
Mail list logo
