On Tue, Oct 26, 2010 at 1:56 PM, Filippo Rusconi <rusconi-deb...@laposte.net> wrote: > > in fact, I understand that you are mainly asking for general packaging > practice details. Have you looked at > > http://www.debian.org/doc/maint-guide/ > > which does a fairly good job at explaining the basics of Debian > package preparation, and which is certainly the most appropriate gate > to making correct Debian packages.
The size of this doc is about 100kB. The average reading speed is about 200 word per minute or about 1.5kB that will about 1 hour for non-technical text. Maint-guide is full of technical details, there are many references to Debian Policy and other docs, you also want to test examples, lookup unknown terms in Wikipedia, so the reading speed drops from 1 to 3-16 hours per manual (depending on your familiarity with unix). Another problem is that I've read it already several months ago, but I didn't need to understand Build-Depends-Indep and rereading this stuff from scratch is kind of ineffective in the end. So, the idea of the previous paragraph is that there should be another entrypoint that explains meaning to people, who primarily use Python rather than for people who primarily use unix. > Section > > http://www.debian.org/doc/maint-guide/ch-dreq.en.html#control > > will enlighten you about Build-Depends-Indep use. Thanks. I've missed this, it helps a little, but not much. Its first attempt to explain Build-Depends-Indep references to Policy 7.7 (which doesn't explain). The second explanation is "Build-Depends-indep is rarely used" and it obviously doesn't explain anything too. Third attempt tells that Build-Depends-Indep may or may not be used to specify packages with "Architecture: all" if they are not "listed in Build-Depends field to satisfy the Debian Policy requirement for the clean target". This sends to Google for Debian Policy requirement for the clean target, but doesn't explain this requirement. Just one more confusing indirection. > Roughly, one way to figure out if you need to specify something in > that field is to ask yourself these questions in order : > > 1. Is my software dependent on the computer architecture (compiled > source code), or is the source code interpreted so that it will run > unmodified on all architectures ? Well, I don't know if Python bytecode could be run unmodified on all architectures. Can it? But I guess Python packages don't ship compiled bytecode, and pure Python packages can run on "all architectures" as well as on "any architecture". What's the difference? From main-guide Build-Depends-Indep is only used with "Architecture: all", but why? > 2. In case the source code is interpreted (like by the Python > interpreter), is that code (in the form of modules or packages) > requiring any particular software to be built ? If yes, you need to > specify the name (and version, if necessary) of the Debian package > that ships that software. If no, you do not need to fill that > field. One example would be that one particular Python library would > be required for your building of the software. That would be > platform-independent software, but still you would require, when > building you software that specific package. You describe Build-Depends record - this one is pretty clear, but what about Build-Depends-Indep? > However, please, note that these are general packaging questions which > should be posted on other mailing lists. In order for your questions > to be well received by the Debian community (which is full of people > willing to help), you should really make sure you have read the basic > documents about packaging (not only Python stuff *all stuff* because > packaging software for Debian requires an extensive understanding of > how software works, not just Python scripts : any software). I understand that I need to read all the stuff and there are specialized lists. The problem that I feel depressed going through this book pile just to be able to bump a version number in small Python package I support in my free time. This is what I'd like to see changed if you want more useful packages in Debian like I do. > A list of useful developer lists is located at > http://lists.debian.org/devel.html, along with an easy subscription > system. ..no search and a lot of spam. =) > Finally, just a suggestion : do not state that you do not want to do > this and this and that learning this and this is not useful... That > kind of behaviour will call for sarcasm from Debianists, precisely > because they became Debianists by not thinking the way you did in a > previous mail. There wasn't so much text back in time, Python folks don't have to use Ubuntu, and Ubuntu didn't encourage people to contribute to Debian first. Back in time there wasn't so many things going on, so you can spend weeks studying exciting Debian infrastructure. I am not skipping rules that everybody is forced to obey - I just don't understand some things that are not clearly explained, and if it causes sarcasm in some Debianists - then maybe its because they are not able to give a link with explanations? You know, back in time people could answer question once and then reference this answer. If it didn't help - they created the FAQ. If person didn't read the FAQ before asking - it was punished. Which point of FAQ I've missed? > Makefile is the name of file which are understood by a program which > is called 'make'. Makefiles are generated by a number of build > systems, amongst which the autotools (GNU project), CMake, and > others. It's good to see you are willing to help, but you may want to > read some basics docs first. I know what is Makefile, but I don't understand why there is no build or build-indep rules there? I thought that Debian Autobuilder is a part of autotools and therefore is somehow responsible for implicit invocation of these targets. > For example, have a look at http://www.gnu.org/software/make/manual/ 500kB plain text. :-( > No need to understand *everything* at first reading!! You just need to > get the general picture. Do this for many docs and you'll get a useful > sight on what programs are and how they should be dealt with in Debian > packaging. I use Windows, because my polished development toolchain is there, but I need Bitten on continuous integration server to test my web application. =( Why do I need to become the follower of Debian church to be able to use it securely? > I hope you will consider Debian as a wonderful "self-development > platform", as the community is generous ; but you should try to be so > also. I see Debian community as generous, but I don't want to lie that I share your vision about platform. For me it is conservative and in many places outdated (email-based bug-trackers, ML without search, HTML manual/policy/docs with boring design, no pictures and wiki-style cross-referencing). But it is still the traditional platform of choice for many organizations to host web apps, and it can be useful. I can be useful for Debian Python community too, provided that I don't have to suffer much in the name of Debian. If you don't like that somebody could suffer less, you are of course free to throw me out. I welcome any sarcastic comments about my revoked SVN access. -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimqpn63cdce=h1ypvhhd3z=a=ldsaaae0goh...@mail.gmail.com
