Re: Build-Depends-Indep dependencies
On Tue, Oct 26, 2010 at 1:56 PM, Filippo Rusconi
<rusconi-debian@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.
Reply to: