On 22 March 2005 at 14:01, Pierre THIERRY wrote: | > severity 300765 wishlist | | Could you explain what gives you the right not to respect a ``must'' | directive in the Debian Policy?
The FHS specifies a Policy that I see as mandatory for base + standard, and as an ideal to strive for for optional and extra packages. It is most important for infrastructure package upon which others build. I see it as a design recommendation for the others. Consider the (faulty) bug report we just had. All I could do right now is to force subdirectories from /usr/lib/R to /usr/share/R and sym-link back. This is a change, and there is non-zero chance of this going wrong or astray as it happened to you with the html files. So for strictly no measurable gain for users of R (who currently get a working system, with Debian providing arguably the best and most comprehensive support of all Linux distributions), we get the non-zero chance of actually breaking something. Not good. And as we're close to a release, I do not see this a good strategy for maintaining high quality R packages. I see merit in your argument, and will raise it again with R Core. This may be a desirable goal for R 2.2.0 (or whatever number will get picked) for October 2005. But in the short term, I do not want to touch this. As an aside, the problem also exists in smaller in every add-on package to R -- do dpkg -L for any of the r-cran-* packages. They all live in their own subtree below /usr/lib/R/site-library (and /usr/lib/R/library/ for the standard ones) mixing arch-dependent and independent files. This is even less likely to change "soon". I appreciate your understanding and patience, and the fact that you refrained from flipping the severity back to the RC level it had before. At this point, an RC bug would keep this well-known and widely-used (see slashdot story earlier today on data analusis for the climate change debate) package out of the next Debian release. I hope that you agree that this would be a bad outcome. Best regards, Dirk -- Better to have an approximate answer to the right question than a precise answer to the wrong question. -- John Tukey as quoted by John Chambers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
