pybuild (Re: image-file-in-usr-lib)
Ben Finney ben+deb...@benfinney.id.au writes: Ole Streicher oleb...@debian.org writes: Installing the non-program files to ‘/usr/share/foopackage/images/’ (for example) is simple enough, using ‘dh_install’. I am using pybuild, and I am wondering why it doesn't do this automatically (maybe with some help)? Generally: pybuild seem to install all files into /usr/lib/? As far as I understand the FHS [1], architecture independent files should go to /usr/share. But, almost all python files (except maybe compiled .so extensions) are architecture independent? * .py sources * .pyc bytecode * .egg-info * helper files in png, xml, txt, ... What is the rationale between having all this in /usr/lib? And what should I do with lintian-warnings like the one above? Just silence them? I am asking a bit rigide here since I wanted to write a small newcomers tutorial to package astropy affiliated packages [2]. These packages are quite standard and therefore a good start for newcomers -- but then the final package should be lintian-clean with not too much efforts. The package I am using as example is wcsaxes [3], and it ends up in quite a couple of /usr/lib/.png lintian warnings. I don't want to explain to a newcomer just ignore these, or make them silent. The Debian Policy [4] states (9.1.1): | 1. The FHS requirement that architecture-independent application- | specific static files be located in /usr/share is relaxed to a | suggestion. In particular, a subdirectory of /usr/lib may be used by a | package (or a collection of packages) to hold a mixture of | architecture-independent and architecture-dependent files. However, | when a directory is entirely composed of architecture-independent | files, it should be located in /usr/share. which is a bit contradicting to the current practice: If it is just a suggestion, then maybe the lintian warning has not right severity warning and should be lowered? And are pure python packages (Architecure: all) not covered by the last sentence and should *not* be in /usr/lib/ by policy? What is the best way here, also to explain this in a tutorial to an absolute newcomer? Best regards Ole [1] http://www.pathname.com/fhs/ [2] http://www.astropy.org/affiliated/index.html [3] https://pypi.python.org/pypi/wcsaxes/0.3 [4] https://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87fv738ujq.fsf...@debian.org
Re: pybuild (Re: image-file-in-usr-lib)
Ole Streicher oleb...@debian.org writes: Ben Finney ben+deb...@benfinney.id.au writes: Ole Streicher oleb...@debian.org writes: Installing the non-program files to ‘/usr/share/foopackage/images/’ (for example) is simple enough, using ‘dh_install’. I am using pybuild, and I am wondering why it doesn't do this automatically (maybe with some help)? Short answer: Because the upstream source does not distinguish which files should be installed where. The help that would be needed is for the upstream source (i.e. the Distutils metadata) to distinguish between executable program files versus non-executable files. Generally: pybuild seem to install all files into /usr/lib/? Yes, because that's what will allow the program to work. We're fighting against an essentially incompatible installation philosophy (“install everything in one dump”) which needs to be untangled in order to meet Debian policy. That can't be done reliably by an automated tool, unless there is some help from metadata set in the upstream source. What is the best way here, also to explain this in a tutorial to an absolute newcomer? I don't have a good answer. The incompatible approaches to installing files, by the disparate packaging systems (Python Distutils versus operating system package managers) needs to be reconciled. -- \ “First things first, but not necessarily in that order.” —The | `\ Doctor, _Doctor Who_ | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85oalra78b@benfinney.id.au
Re: pybuild (Re: image-file-in-usr-lib)
Le Mon, May 11, 2015 at 09:03:53AM +0200, Ole Streicher a écrit : The Debian Policy [4] states (9.1.1): | 1. The FHS requirement that architecture-independent application- | specific static files be located in /usr/share is relaxed to a | suggestion. In particular, a subdirectory of /usr/lib may be used by a | package (or a collection of packages) to hold a mixture of | architecture-independent and architecture-dependent files. However, | when a directory is entirely composed of architecture-independent | files, it should be located in /usr/share. which is a bit contradicting to the current practice: If it is just a suggestion, then maybe the lintian warning has not right severity warning and should be lowered? And are pure python packages (Architecure: all) not covered by the last sentence and should *not* be in /usr/lib/ by policy? Hi Ole, indeed, this is a recent change in the Policy (see bugs.debian.org/741304). Probably Lintian is lagging behind. Maybe somebody can ping bug #415558 ? Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2015051108.ge1...@falafel.plessy.net
Re: pybuild (Re: image-file-in-usr-lib)
On 05/11/2015 09:03 AM, Ole Streicher wrote: Ben Finney ben+deb...@benfinney.id.au writes: Ole Streicher oleb...@debian.org writes: Installing the non-program files to ‘/usr/share/foopackage/images/’ (for example) is simple enough, using ‘dh_install’. I am using pybuild, and I am wondering why it doesn't do this automatically (maybe with some help)? Generally: pybuild seem to install all files into /usr/lib/? As far as I understand the FHS [1], architecture independent files should go to /usr/share. But, almost all python files (except maybe compiled .so extensions) are architecture independent? * .py sources * .pyc bytecode * .egg-info The FHS never talks about putting *code* into /usr/share. So pybuild is right from my point of view to put it in /usr/lib. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55507195.9010...@debian.org
Re: pybuild (Re: image-file-in-usr-lib)
Matthias Klose d...@debian.org writes: The FHS never talks about putting *code* into /usr/share. So pybuild is right from my point of view to put it in /usr/lib. I think the Debian Policy is quite clear here: | [...] However, when a directory is entirely composed of | architecture-independent files, it should be located in /usr/share. The policy talks about when to put *files* into /usr/share. code files are also files, so they should (from the policy point of view) make no exception. And, in fact there is no difference between emacs .el(c) files, perl .pl files, and python .py(c) files, right? Do you think perl is wrong putting their files to /usr/share? Even if the FHS speaks about data files, they (in my opinion) suggest that this includes code: | It is recommended that application-specific, architecture-independent | directories be placed here. Such directories include groff, perl, | ghostscript, texmf, and kbd (Linux) or syscons (BSD). They may, | however, be placed in /usr/lib for backwards compatibility, at the | distributor's discretion. (the last sentence is clarified by the Debian Policy). I don't want to argue that python should move to /usr/share; however it would be nice (especially for beginners) if policy, lintian, and reality would match here. And I am just trying to find out whom to ask for a change. So, do you think it is just Lintian? Shall I put the recommendation make lintian silent here in my tutorial? Best regards Ole -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87vbfza17r@news.ole.ath.cx
Re: pybuild (Re: image-file-in-usr-lib)
Charles Plessy ple...@debian.org writes: indeed, this is a recent change in the Policy (see bugs.debian.org/741304). Putting pure python packages (Architecture: all) into /usr/lib is IMO still not coved by the Debian Policy. Probably Lintian is lagging behind. Maybe somebody can ping bug #415558 ? I'll do that. Cheers Ole -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87r3qna0yt@news.ole.ath.cx
Re: pybuild (Re: image-file-in-usr-lib)
On 11/05/15 08:03, Ole Streicher wrote: What is the rationale between having all this in /usr/lib? Conversely, it might be informative to consider the rationale for /usr/lib and /usr/share being separate: This hierarchy is intended to be shareable among all architecture platforms of a given OS; thus, for example, a site with i386, Alpha, and PPC platforms might maintain a single /usr/share directory that is centrally-mounted. Note, however, that /usr/share is generally not intended to be shared by different OSes or by different releases of the same OS. ... but does anyone actually do this? It's not as if dpkg really supports it. If I was trying to provide NFS-mounted root filesystems or /usr for multiple architectures, my process would go more like this: * stop doing that, it's 2015; * failing that, have a chroot per architecture; * if necessary, deduplicate with btrfs reflinks; * if not on btrfs and disk space is short, deduplicate with hardlinks S -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/555128c2.5090...@debian.org
