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

Re: /usr/doc transition and other things



On 1 Sep 1999, Manoj Srivastava wrote:

> Hi,
> >>"Dale" == Dale Scheetz <dwarf@polaris.net> writes:
> 
>  Dale> On Tue, 31 Aug 1999, Joey Hess wrote:
> 
>  >> Nope, you don't get it.
> 
>         How to win friends and influence people ;-)
> 
>  Dale> As the rest of the committee seemed to take your proposal as
>  Dale> being "not to the point" I submit that I'm not the one who
>  Dale> "don't get it".
> 
>  Dale> If it isn't "maintain the old location during the transition"
>  Dale> then please inform my ignorant self, as I may need to change my
>  Dale> vote.
> 
>         There are two issues involved:
>  a) The principle of least surprise, which is the frustration involved
>     in reading the docs in two different locations. The symlink
>     solution addresses this 
>   b) incremental upgrades to unstable packages from unstable, which
>     makes documentation not be accessable with tools such as dwww,
>     man, ect. Joey's stable upgrades solution addresses that.

It was my understanding that this situation could be resolved in the same
fashion that the man and info transitions were. By making the docs viewing
programs aware of both the old and new locations, and back porting them
into slink, the broken tools issue is resolved.

In fact there is no real need to back-port these fixed tools into slink.
You only need to make the transitioning packages depend on the newer
version of the viewers and even incremental upgrades will work just fine.
(note, we do this all the time with libc when it breaks older versions of
other, unrelated, packages)

As a result, it was my understanding that (b) was a moot point and not
what we, as the technical committee, were being asked to resolve.

> 
>         The stable-upgrades solution has no impact on the former
>  problem, and the symlinks solution only addresses the latter in a non
>  optimal fashion. The symlink solution does have the side effect of
>  making (b) above less critical, though.
> 
>         I never made (b) a part of my proposal either before the
>  policy list of before cebian-ctte, since I felt that a) was important
>  enough to require a solution, and it made (b) less time critical, and
>  we could deal with it by ensuring that all the packages in potato
>  dealt with /usr/share/doc.
> 
>         The symlink solution would ensure that partial upgrades to
>  potato would work with man/info/whatever packages that had not been
>  upgraded, and since potato should have fixed packages, partial
>  upgrades from potato to woody would work as well.
> 
It appears that you intend the symlink farm to extend to man and info
pages as well? That was not clear in your proposal to the committee.


>         Partial upgrades from slink to woody would have problems, but
>  adding stuff to slink-updates (Joey's proposal) would fix that.

As would adding dependencies to the appropriate packages.

> 
>         With the symlink proposal adopted, Joey's proposal would only
>  be required for partial slink-->> woody upgrades.
> 
Not if proper dependencies are used.


>         manoj
> -- 
>  In the next world, you're on your own.

What's new about that! I seem to be on my own in this world as well ;-)

Luck,

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz                   Phone:   1 (850) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  dwarf@polaris.net     Tallahassee, FL  32308

_-_-_-_-_-_- See www.linuxpress.com for more details  _-_-_-_-_-_-_-


Reply to: