| |||||||||||||
|
| |||||||||||||
Policy-respecting .debs?Policy-respecting .debs?Posted Sep 1, 2008 18:22 UTC (Mon) by GreyWizard (subscriber, #1026)In reply to: Policy-respecting .debs? by tzafrir Parent article: Bitten by the Red Hat Perl bug (InfoWorld)
Something is inscrutable when it is not readily understood, not merely when it's utterly incomprehensible. So I can't give you an example of a lintian error or warning I'm not able to comprehend after enough research. But I can give you examples that aren't obvious to someone who is not a Debian expert but is capable of building software packages:
E: <pkgname>: no-shlibs-control-file usr/lib/lib<pkgname>.so.0.0.0
Digging up the meaning of these is possible, and I've done it, but it's rather a lot of bother compared to the process of creating an RPM.
As for examples of the arcane I hardly know where to begin. Why should I need a shlibs control file for a simple libtool shared library? Aren't there reasonable default assumptions that could be made? Why is it forbidden to set the executable bit on such libraries? That's the way they come out of the build process after all and somehow RPM based distributions survive that calamity. Why is it wrong to ship .pyc files? Why should my .py files be executable when they are meant to be used only as libraries (I feed the files to python directly when running built-in unit tests)?
I'm sure there are answers to all of these questions for those with the fortitude to dig through the Debian Policy Guide -- and do enlighten me if you happen to know them. But the notion that such exhaustive policy is necessary to make a large distribution coherent just isn't credible.
(Log in to post comments)
Policy-respecting .debs? Posted Sep 1, 2008 20:44 UTC (Mon) by vmole (guest, #111) [Link] Digging up the meaning of these is possible, and I've done it, but it's rather a lot of bother compared to the process of creating an RPM. So the fact that Debian provides tools that point out mistakes in packaging is bad. Hmmm. Do you turn off compiler warnings that you don't understand? I can't speak to the shared library issues, but the reason you don't ship .pyc files is so that the install system can build the python version specific .pyc files according to which versions are on the user's system. Also, you don't ship preprocessed man pages, right? And I don't know why you think python library files have to be executable; the ones on my system aren't. Finally, if these are real issues, you should discuss them on the Debian python list, where the experts are. Finally, it should be noted that pretty much every item in Debian Policy is there for reason, for solving a real problem. They don't add stuff just to be difficult. Sometimes it's "do X because Y is wrong", and sometimes it's "We can do X or Y, either would be right, but we choose X." Consistency is worth something.
Policy-respecting .debs? Posted Sep 2, 2008 15:50 UTC (Tue) by GreyWizard (subscriber, #1026) [Link]
Where do you find evidence to support the absurd conclusion that I would prefer to have policy problems hidden from me? I'll go through this again using small words: the policy is complex, the lint tool mumbles and the documentation is poorly organized. Your explanation about .pyc files makes sense and I would thank you for it if not for the tone of the rest of your post. I don't know why .py files should be executable. All I know is that lintian complains when mine aren't. Perhaps there is some arcane incantation I haven't mastered which makes that acceptable. And yes, I know there are reasons for the policy -- in fact I said exactly that the message you replied to. (Consider reading posts before you reply to them in the future.)
But having a reason is not the same as having a good reason. From the perspective of an outsider who just wants to create a policy compliant package the documentation, tools and (at least if you are a representative example) developers are decidedly unfriendly. In light of that the fact that packages created by people who aren't committed Debian developers are "policy-ignoring disasters" is no surprise.
Policy-respecting .debs? Posted Sep 2, 2008 17:25 UTC (Tue) by vmole (guest, #111) [Link] And we are back to my original point: upstream developers often do not have the time or interest to create proper distribution packages. That's fine. Leave it to the experts. That's the whole point of a distribution: combine hundreds or thousands of disparate pieces of software into a coherent whole. Why would you expect that to be simpler than a writing a single program?
Policy-respecting .debs? Posted Sep 2, 2008 18:13 UTC (Tue) by GreyWizard (subscriber, #1026) [Link]
Attempting to create a policy compliant package (and even arguing about the obstacles) is a way of trying to contribute in a small way. You seem to be suggesting that anyone who isn't willing to make the large investment of time and effort to actually become a Debian developer shouldn't be bothering at all. I can live with that. It doesn't cost me anything to stop running lintian. But giving up community good will for .so files without executable bits seems like a poor trade to me.
Policy-respecting .debs? Posted Sep 2, 2008 18:49 UTC (Tue) by vmole (guest, #111) [Link] No, I'm suggesting that anyone who isn't willing to read the relevant parts of Policy, and fix the relevant lintian errors, should let someone else build the distro-specific packages. Supplying broken packages is NOT contributing. If you want to contribute to the Linux Kernel, then you are expected to understand how the parts work, and to follow the established coding conventions, even if you don't see the point of them. And just to be perfectly clear: I don't think you are a bad person for not wanting to invest the time. Lots of people can (and do) create distro packages. They're good at it. You should spend your time doing whatever it is you want to do, and do it well. Better you fix a bug in your code, or add a feature, than worry about Debian shared library permissions.
Policy-respecting .debs? Posted Sep 2, 2008 19:45 UTC (Tue) by GreyWizard (subscriber, #1026) [Link]
Why would I run lintian at all if I thought supplying broken packages was acceptable? I complained about a few specific cases where the policy is arcane because I was explicitly asked to do so above, not because I believe I shouldn't have to follow the established conventions.
I'm touched by your concern for how I spend my time, but arguing against points I haven't actually advanced is probably not a good use of yours.
Policy-respecting .debs? Posted Sep 2, 2008 9:58 UTC (Tue) by tzafrir (subscriber, #11501) [Link]
In that case you should run lintian with the option -i to provide you more information about those errors/warnings , as well as a reference to thew relevant section in the policy manual.
no-shlibs-control-file:
Although the package includes a shared library, the package does not
Section 8.6: http://www.debian.org/doc/debian-policy/ch-sharedlibs.htm...
non-dev-pkg-with-shlib-symlink:
Although this package is not a `-dev' package, it installs a
Shared libraries are supposed to place such symbolic links in their
However, if this is a small package which includes the runtime and the
Section 8.4: http://www.debian.org/doc/debian-policy/ch-sharedlibs.htm...
The executable bit should only be set where it is needed. For scripts. Shared libraries don't need to be executable. If you use the recommended toolchain this will mostly be done for you. I can't think of a specific problem caused by this, but this is the general rule here. Don't mistake /usr/lib for /usr/libexec .
As for the other issues you have raised:
I'm not sure I can easily answer all of your questions. But here's an example: you don't ship .pyc files because you can't tell in advance with what version of python (and potentially: with what other libraries) the code will build. So those are likely to change. See the python policy manual for the exact details:
Also, if the file is has a '#!', it is probably intended to be executable. If you have some python code that is only intended to be used as a module and not as an executable, remove the '#!' from the first line. Chances are you merely forgot to set a script as executable (note that lintian here gives you a warning rather thna an error). Actually python modules are often have a small main for a simple test driver.
Policy-respecting .debs? Posted Sep 2, 2008 16:02 UTC (Tue) by GreyWizard (subscriber, #1026) [Link]
That's quite helpful, thank you. Still, the point I'm trying to make is that all this is quite hard to master. There are surely things Debian can do to be more friendly to people who want to create packages that conform to their policies. One concrete suggestion is to make the more informative mode the default for lintian. Experts can set whatever switch is necessary to get more concise output.
|
|
||||||||||||