On Wed, Sep 24, 2003 at 10:42:15PM -0500, Terry Hancock wrote: > On Wednesday 24 September 2003 07:13 pm, Zed Pobre wrote: > > On Wed, Sep 24, 2003 at 06:31:35PM -0500, Terry Hancock wrote: > > > My package installs into /opt/iraf/iraf which seems to make sense > > > from the FHS standard, > > This is only correct for third-party packages. Packages that are > > part of a distribution belong in /usr, and to conform to Debian > > policy, IRAF needs to install mostly into /usr/lib/iraf, with > > architecture-independent components in /usr/share/iraf and > > user-accessible binaries (such as cl) accessable via /usr/bin. I > > previously had it installing in /usr/iraf, pending closer examination > > of the assumptions IRAF was making about where files were, but this > > (correctly) drew a bug report, and packages altering the contents of > > /opt won't be allowed into the distribution at all. > Um, basically, I think we're going to get into a serious conflict here, > or else this just means IRAF will remain a "3rd party package." The > thing is, it just does not make any sense to break IRAF up like > that -- it completely defeats the purpose of packaging it, because > it violates the users' expectations of it. > Where you put IRAF is negotiable, but how it is internally structured > is not. I pushed that to what is probably its absolute limit by moving > the tapecap and external package definitions to /etc (the symlinks > remaining in the IRAF tree make this tolerable). > Please remember that I have time to package these things because > I'm paid by users to keep it working, and packaging it for Debian > happens to be a good way to do that. But I can't betray their > interests just to satisfy some procrustean 3rd party policy. IRAF has > a particular structure that it needs to keep to satisfy its users, and > to make it network-installable, etc. I can't just tear it apart and > expect that all to keep working, and the users wouldn't trust it if > I did. They'd just ditch it and use an alternative source. Which would > make this a phenomenal waste of my time! Then there's no sense in trying to include it in Debian. The FHS is not optional for Debian packages; it's part of how we ensure that the operating system we're creating is internally consistent. So for the package to be included in Debian, it must obey certain constraints so that the expectations of *Debian* users are not violated. > Besides, IRAF is older than Debian, I think its design has seniority. ;-) AIX is also older than Debian. Just throw the whole thing under /etc and call it good. :P > > The /opt and /usr/local areas are for the system administrator to > > play around with, and even if he or she has "apt-get dist-upgrade" in > > a cron job, nothing that Debian packages do should ever affect the > > files stored there. > Well, the FHS says /usr/local is for the sysadmin, and opt is for > 3rd party packages. > IRAF is not alone in being package-oriented, either: AIPS, AIPS++, > and CIAO will all insist on their own structure (and I get to do them > just as soon as I finish with IRAF). I think there are enough such > packages in the world, that Debian policy ought to have room > for them. Debian Policy governs only Debian packages, where "Debian packages" means "packages distributed by Debian." If they're distributed by Debian, they are by definition NOT third party, and therefore cannot touch /opt. > I'll think about it some more, but I'm not convinced that the concept > of breaking it up into /usr/share, /usr/lib, /usr/bin can work. At best, > we might be able to put everything under /usr/share/iraf and use > symlinks to satisfy the policy. This has been done before; see mailman for a well-executed example. -- Steve Langasek postmodern programmer
Attachment:
pgpD2V662CxGP.pgp
Description: PGP signature