Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
> > For my current system I have defined the following packages as
> > build-essential:
>
> I wanted to avoid naming specific packages in Policy (I only named two in
> the proposal, make and dpkg-dev), since packages change and it would be a
> pain in the rear to change policy every time GNU Libc changes name, for
> example.
I didn't mean to mention package names explicitly, I wanted to give an
example what is currently considered build-essential.
> > Depends-Sourcetree: tcl8.0 ("ln -s tcl8.0-* tcl8.0; cd tcl8.0; ./configure --prefix=/usr")
>
> I want to keep this proposal as clean as possible; I don't want to see this
> kind of kluging in it if at all possible. My intent is to let this proposal
> to handle the majority cases. The tough minority will need to be dealt with
> separately (for example, by using your central dependencies forever for
> these packages).
You asked for ideas for solutions :-) But solutions for this kind of
thing are always kludges, I fear :-( For my part, I don't insist on
making this policy, of course. It was just an idea.
> I tried to phrase the proposal (ie the diff) so that this would be
> true. Did I fail?
Maybe I haven't read it closely enough... I looked it through again,
and I think what's allowed as value of the fields is said only
implicitly (because the fields have the same names as their
counterparts for binary packages). I'd state it explicitly, as you
explicitly say that virtual packages are allowed, just for clearness.
> > - You don't need to specify packages that are dependencies of another
> > package that is already a source dependency, provided that nothing
> > is used explicitly from the first package.
>
> Agreed. Do you want to write the language for the Policy? I'll
> accept it as a part of this proposal, if you do.
Oom... I guess I'm not good at wording :-) Let's try anyway:
+ <p>
+ It is not necessary for a source package to specify
+ dependencies on the following packages: packages which are
+ marked <tt>Essential</tt>; packages with the priority
+ <tt>required</tt>; the <tt>dpkg-dev</tt> and <tt>make</tt>
+ packages; and packages which are required for compiling
+ and linking a minimal "Hello World" program written in C
+ or C++. Runtime library packages should not normally be
+ specified in source dependencies.
+ </p>
++ <p>
++ You also should not specify binary dependencies of
++ packages that are source dependencies, because those
++ binary dependencies might change in future. And for the
++ purpose of installing all source dependencies, they can
++ be determined automatically. You should, however, specify
++ a package even if it is a binary dependency of another
++ source dependency if something from it is used explicitly
++ during the build process, for the same reason. If the
++ package isn't a binary dependency anymore in future, your
++ source dependencies would become incorrect.
++ </p>
Please feel free to improve this...
> > - If a dependency on a -dev package is given, it must be a versioned
> > dependency if needed to ensure that the resulting (binary)
> > dependencies of built packages are unchanged.
>
> Again, can you suggest a wording?
++ <p>
++ Source dependencies on development packages of shared
++ libraries must be properly versioned, so that if the
++ package is rebuilt with any -dev package that satisfies
++ the version requirement the resulting binary dependencies
++ on shared libraries (as output by dpkg-shlibdeps) are
++ always the same. In other words, all shared library
++ packages installable with allowed -dev packages must have
++ an equivalent shlibs file.
++ </p>
Sounds complicated :-( ...but seems to be a complicated matter in any way.
Roman
Reply to: