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

Re: [Result] Moving to the FHS: ...



On 5 Sep 1999, Manoj Srivastava wrote:

> Hi,
> 
>         Unless someone else volunteers, I could come up with a
>  suggested language to be included in policy. It would be
>  updated with Raul's suggestions about not making all current packages
>  instantly buggy, and allowing the FSSTND conforming packages to be
>  legal but deprecated.
>
>         I would also produce a non-policy ``strategy'' document, which
>  shall include the other aspects of this proposal, namely, when
>  the FSSTND would go from being deprecated to being illegal,
>  and how we can get rid of symlinks later.

Mmm, let's see if I understood this "deprecated vs illegal" thing.

Suppose I decide, for the packages I have not converted yet, not to move
to /usr/share/doc until the "last minute". Will I get bug reports?
Will my packages be NMUed?

I imagine the following scenario:

slink: everybody uses /usr/doc.

potato: mix /usr/share/doc and /usr/doc but people using /usr/share/doc
        should use symlinks.

potato+1: we deprecate symlinks but still allow them, make /usr/doc
          illegal, and start filing bugs against packages still
          using /usr/doc. [ This is of course not decided yet, it's just
          an hypothesis ].

potato+2: we make symlinks illegal and start filing bugs against packages
          using them. [ This is just another hypothesis ].

[ BTW: How do these hypothesis sound as a proposal? ]

Since I don't think maintaining Debian packages should be *gratuitously*
painful, what kind of technical problems would my packages cause to the
average Debian user if I decide to move from /usr/doc to /usr/share/doc in
one shot and without symlinks during the unstable stage of potato+1?

I guess if we are going to be "permissive" about packages still using
/usr/doc in potato, we should probably be permissive as well about
packages not using symlinks when they are not really needed.

Comments?

Thanks.

-- 
 "be6eecf65d5db0cae0fc123bdefc8074" (a truly random sig)


Reply to: