Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
> What if you can only uninstall the package by deconfiguring another one > that you need? Take this situation: > > foo-source has > Build-Depends: gnu1 | gnu2 > Build-Conflicts: bar > > gnu1 has > Depends: bar > > Currently bar and gnu1 are installed. Will your five lines of code be > able to uninstall bar, uninstall gnu1, and install gnu2? First: The ~ 5 lines were for additional support of negative dependencies. Second: sbuild currently doesn't support alternatives yet :-( Third: Dependency calculations et al. are passed on to apt-get, so they make up no code :-) > Hmm, lprng Provides lpr (and Conflicts with it). I guess this > expresses that lprng won't do. Ah, that sounds like an explanation, yes. Isn't this a good reason for Build-Conflicts:? A simple Build-Depends: lpr could be satisfied by lprng as well, but it's wrong since a2ps needs real lpr, not lprng. > They should be configured not to use svgalib, via options in debian/rules. > This should not depend on the build environment. (If it does, it's > far too easy to silently build without it, even on a platform that > does need it). This is the case for many, really many libs :-( It was one of the reason we've "invented" source dependencies. You simply can't hardwire all lib dependencies as options to configure. > Also a packaging bug. Bash should be told to use libncurses, > regardless of the build environment. Also if you have to patch a really correct upstream configure? (I assume there's no option for disabling libtermcap.) > (and so forth)... these should all be told to configure the right > way, regardless of build environment. Build-time configuration is > nice, but not if you want the binary package to be easily > reproducible. ...but often configure scripts aren't flexible enough so that you can select all options from the command line :-( > I've already seen far too many bugs in NMUs caused by packages > silently built with the wrong configuration. And this hopefully will come to an end with source dependencies! Roman
Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
> Can we use a format that is more inline with the rest of the depends > stuff? Perhaps: > > pkg (>= 2.1 i386) > > With the 'i386' being whatever specification you want to dream up. > (optional of course) At least better to parse than "package7(CPU1, >= 2.0)", as the version can't contain spaces and anything following it must be an arch spec. Roman
Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
> Are the -Conflicts headers really necessary? So far I have not been
> able to think of a use for them, and they complicate the task of the
> build daemons ("install everything needed to build this package")
> unnecessarily.
That's not really true. The parsing is nearly the same, and it's no
trouble in sbuild to deinstall packages as that's needed anyway after
the build. I guess the negative deps (as I have called them in sbuild)
make about 5 lines of code.
> We've already seen with binary dependencies that the Conflicts
> relationships create the most difficult problems.
But it's something different here... It's really trivial to
temporatily uninstall a package and reinstall it later.
> - Problem: There are two conflicting development environments (let's
> call them tk40-dev and tk41-dev :-), and foo needs the right one.
> Solution: foo declares a Build-Depends on tk41-dev, and tk41-dev
> conflicts with tk40-dev.
Yep, it's already done this way without problems and without the need
for build-conflicts.
> - Problem: Package foo needs debassistant >= 0.8 to build, but
> will not work with debassistant version 0.93 which has a horrible bug.
Yep :-)
> Solution: foo declares
> Build-Depends: debassistant (>= 0.8),
> debassistant (<< 0.93) |
> debassistant (>> 0.93)
Ok (though a bit complicated, but doesn't matter, it should be rarely
necessary.)
> If package foo has Build-Conflicts: bar, it means that the *presence*
> of bar will prevent foo from building correctly. I consider that a
> bug! Adding support for this would condone such bugs.
Hmm... Let's see where such conflicts are used currently:
a2ps => !lprng, lpr, gs, psutils, bzip2, gv, ghostview, gettext, flex
Hmm... don't remember exactly anymore, but I guess lpr is needed and
doesn't like lprng in parallel.
abuse => !svgalib-dummyg1
gnuplot => !svgalib-dummyg1, gnuplot
Some packages would configure for svgalib if svgalib-dummy is installed.
bash => !termcap-compat
If termcap-compat is installed, configure will detect libtermcap
before libncurses and link with the former.
emacs20 => !emacs20
AFAICR emacs used the installed lisp files instead of the ones in
the build dir, but this has been fixed some time ago.
liece => emacs20, !libsocks-dev
Can't remember... :-(
plplot => g77, !f2c, itcl3.0-dev, python-numeric
f2c doesn't conflict with g77, but is preferred by the config.
rpm => !bzip2, m4, gettext, autoconf, automake, tetex-bin
If bzip2 is installed, librpm.so will be linked with libbz2.so,
which is unwanted.
ruby => bison, !ruby
And installed ruby can provoke version conflicts of the installed
lib and the built lib.
I think at least the cases of bash, plplot, and rpm are no bugs.
Roman
Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
On Mon, 2 Aug 1999, Roman Hodek wrote: > > > Your naming is weird ;) s/ARCH/CPU/, s/OS/SYSTEM/ and I'm your > > friend. > > If it makes you lucky, think the vars re-named :-) But it really makes > no difference, I meant exactly the same as you, i.e. ARCH == cpu. > > > Looks good to me. I don't know how many logical operators we should > > support, but it goes in the right direction. I am also unsure about > > the colon (:) as seperator. > > The | operator seems necessary when a package needs e.g.svglib on i386 > and alpha and nowhere else. The ! operator is necessary to avoid > listings of all archs except one. Such lists have to be extended > whenever there's a new Debian arch, and this calls for bugs. > > And I think the colon is as good or bad as anything else, so why not? Can we use a format that is more inline with the rest of the depends stuff? Perhaps: pkg (>= 2.1 i386) With the 'i386' being whatever specification you want to dream up. (optional of course) I would suggest that any depends element that has an unmet arch specification would simply be ignored (evaluate to 'true'). Jason
Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
> I would like to use this suggestion. Comments? See my previous mail: I'd say the -Arch variants are unnecessary, but if everybody wants them for clearness of design, I won't oppose. > Sounds good. Actually, that was what I had originally in mind. If > there are no objections, I'll make this part of my proposal > (seconders: I need your comments!). Ok with me. > > I think that texinfo shouldn't be there. > > Agreed. texinfo etc. were out of the games for a long time, I thought :-) > I see the point of this suggestion, but I'm not sure the wording is > wise. We can't expect to be able to compile the unstable > distribution while satisfying build dependencies with packages in > the stable distribution (think of Gnome in potato or a libc upgrade, > for example). I think you've mis-read Ian's statement here. He didn't say that source dependencies might be satisfied from stable only (this would indeed be nonsense). But a consequence is that the src-deps must be properly versioned so that the appropriate packages from unstable are installed. Roman
Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
> I strongly agree with the proposal. Nice to have you on the boat, too :-) > I disagree with Roman's suggestion that we should remove the Arch- > versions because they'd not be used often. I think it important that > the resulting scheme be orthogonal. It should also parallel the > `binary-*' targets in debian/rules. The current fields are as (un-)orthogonal as the dpkg-buildpackage options are: You can use -B to build without Arch: all packages, or you can build all packages. I see your point, and I can live with the Arch- variants if a majority wants them. But I still think they just make more work, both for maintainers who have to define them, and for tools which read source dependencies. There's no (official) possibility to build only the Arch: all packages, and this also doesn't make much sense in most cases. > I think that instead the formulation about `compile and link a trivial > C or C++ program and put it in a Debian package' should be the > defining one. We can supply a list of example packages, but we should > explicitly state that it's only an example which was `true at the time > of writing'. This seems like the footnote idea... > Build-time dependencies must specify version number(s) of package(s) > if the version in the current Debian stable distribution is not > adequate. If this is necessary usually a >= dependency should be > used. This looks like an important point. Anybody against it? > It is a bug if, after unpacking the source package on a system > running the current stable distribution, and satisfying the source > dependencies (including the implied dependencies), you cannot build > the package and produce a working binary package suitable for > installation into the binary distribution corresponding to the > source distribution which contained the source package. Ok, this explicitly says what's the intention of source dependencies. It's correct that this hasn't been said in a formal way yet. For my part, we can add it, too. Roman
Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
> Yes, consider that a typo. I will not submit another patch as the > fix is obvious. Yep, that's what I thought as I seconded the proposal :-) Roman
Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
On Fri, Jul 23, 1999 at 06:23:09PM +0200, Roman Hodek wrote:
> Isn't that wrong? I think Build-Indep-{Depends,Conflicts} apply only
> to 'binary-indep' (and transitive to 'binary'), but not to 'build'.
> Otherwise, you'd have to install Build-Indep-Depends also for the pure
> build...
Yes, consider that a typo. I will not submit another patch as the fix
is obvious.
--
%%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
"... memory leaks are quite acceptable in many applications ..."
(Bjarne Stroustrup, The Design and Evolution of C++, page 220)
Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
> - The fields change as follows:
>Depends -> Build-Depends
>Arch-Depends(removed as suggested by Roman Hodek)
>Indep-Depends -> Build-Indep-Depends
>Conflicts -> Build-Conflicts
>Arch-Conflicts (removed as suggested by Roman Hodek)
>Indep-Conflicts -> Build-Indep-Conflicts
>(The rename suggested by Steve Greenland)
Ok.
> - The syntax of the fields is explicitly mentioned to be
>identical to binary Depends et al. Mentioning redundant
>packages is explicitly discouraged. Strict versioning
>for -dev packages must be used.
>(Suggested by Roman Hodek.)
Ok.
> The following suggestions will NOT be part of this proposal. They may
> be proposed separately if necessary.
Ok.
> +
> +
> +The Build-Indep-Depends and
> +Build-Indep-Conflicts fields apply to the targets
> +build, binary and
> +binary-indep.
> +
> +
> +
> +
Isn't that wrong? I think Build-Indep-{Depends,Conflicts} apply only
to 'binary-indep' (and transitive to 'binary'), but not to 'build'.
Otherwise, you'd have to install Build-Indep-Depends also for the pure
build...
Except that (probable) leftover from the previous version, I formally
second the proposal.
Roman
Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
> Well, if the first stanza is global, how about being able to put the > fields in the other stanzas too, to control dependancies on a > per-binary-package basis? You would need to name them prefix, > though. This seems possible, but I can't see the real advantage of it. You really seldom build sub-packages on their own... and your suggestion only makes it harder to parse the control file for source dependencies. Roman
Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
> Small comment: I like the informal way the "build-essential" > packages are described. However, for practical reasons, it would > help to specify also which ones they are at a given time. For > example: > > [...] and packages which are required for compiling and linking a > minimal "Hello World" program written in C or C++ (currently the > following ones: binutils, libc6-dev, gcc, [...]). Such a list will be helpful for many people, I think. I'd also like such a list, but... > The idea would be to provide a real list, but also the rationale > from which the list is derived, so that whenever the list of > build-essential packages change, we just update policy accordingly, > without changing the spirit of it. How does this sound? Ok, you don't change the spirit of policy, but you nevertheless have to change it... And as experience shows, the updates are often enough forgotten. So I understand Antti's objections against explicitly listing some packages. What do others think about this? Roman
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:
+
+It is not necessary for a source package to specify
+dependencies on the following packages: packages which are
+marked Essential; packages with the priority
+required; the dpkg-dev and make
+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.
+
++
++ 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.
++
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?
++
++ 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.
++
Sounds complicated :-( ...but seems to be a complicated matter in any way.
Roman
Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
> The build bot people have a partial solution of their own. Yet, we
> still don't have a general way of specifying these dependencies in
> our packages.
Yep, and I agree that we should have such a thing. The "partial
solution" you mention is a (complete) central database of source
dependencies, and that was the only way to make the system going. If I
would have waited for every package coming with appropriate src-deps,
we wouldn't have a buildd system yet...
> My proposal is, in short, the following: Define six new fields for
> debian/control and specify their meaning. The six new fields are used
> only in .dsc files and in the first paragraph of debian/control. They
> are:
>* Depends
> Specifies the packages that must be installed when one of
> the targets build, binary, binary-arch and binary-indep
> of debian/rules is invoked.
>* Arch-Depends
> This is a variant of Depends which is followed only when
> the architecture-dependent parts of the package are being
> built.
>* Indep-Depends
> This is a variant of Depends which is followed only when
> the architecture-independent parts of the package are being
> built.
>* Conflicts, Arch-Conflicts, Indep-Conflicts
> These are analoguous to the dependency fields above.
This looks fine so far.
Just one note: Arch-{Depends,Conflicts} might be unnecessary, as it
should be very rare that someone only builds the arch-indep packages.
So we could merge Arch-Depends into Depends. If one compiles with
dpkg-buildpackage -B, he needs to look only at Depends.
dpkg-buildpackage without -B needs to look at Depends + Indep-Depends.
> It will not be necessary to specify "Essential: yes" or "Priority:
> required" packages, nor is it necessary to specify a minimal
> standard C and C++ compilation environment. The dpkg-dev package is
> also assumed to be installed. Helper packages such as debhelper, if
> any, *must* be specified.
For my current system I have defined the following packages as
build-essential:
- gcc
- g++
- binutils
- make
- fileutils
- shellutils
- libc6-dev
- libstdc++*-dev (current version)
- texinfo (really many packages need makeinfo from it)
- perl-5.005
- dpkg, dpkg-dev
- debhelper, debmake
The differences to your proposal are:
- texinfo is only Priority: standard, but it's really needed by lots
of packages (for makeinfo). I'm just too lazy to add tons of texinfo
src-dependencies...
- perl-5.005: only perl-base is essential; but the whole buildd
system is written in Perl itself, so it has to be installed anyway,
and it would be wasting bytes to mention it explicitly. But it
could make sense to mention perl in per-package src-deps.
- debhelper, debmake: used by so many packages again... and again, it
would make sense to mention them in per-packages dependencies.
> It needs a central repository of dependency information, and the way
> to inform that repository of changes in packaging is not well known.
So let's make it known here now :-) The sources of the src-deps are in
a CVS repository on :pserver:cvs.linux-m68k.org:/CVS, module name
srcdep. Anonymous read access is possible, and currently all buildd
admins have write access. But I don't want to give write access to a
broad public (e.g. all Debian developers), as some knowledge is needed
how the system works to modify the sources properly. And bad
modifications can easily make a lot of things fail for the build
daemons...
> This proposal does not deal with the fact that some packages need to
> have particular *source* packages unpacked and even perhaps
> partially built at the time of a build. Those issues are more
> complex and requires more study - perhaps the sbuild folks who have
> dealt with them can offer a solution?
My current src-deps have a solution, but it's more a hack than a
solution... sbuild knows so-called "special dependencies" that are no
packages to be installed but are defined themselves in the src-dep
file. Special deps can execute shell scripts before and/or after the
build, and can apply patches under conditions. And in such a shell
script, you can unpack some other package and e.g. configure it.
But for per-package src-deps we would need a better mechanism, of
course. What about the following: We additionally have a
Depends-Sourcetree: field that lists packages that are expected
unpacked. An entry there can be augmented by shell commands:
Depends-Sourcetree: tcl8.0 ("ln -s tcl8.0-* tcl8.0; cd tcl8.0; ./configure
--prefix=/usr")
The source package for package tcl8.0 will be unpacked (with
dpkg-source -sn -x) in the directory where also the build dir for the
current package is. If shell commands are given in parens, they're
executed in a subshell.
Maybe hackery, too, but requiring unpacked and configured source tree
Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
On Tue, 13 Jul 1999, Antti-Juhani Kaijanaho wrote: Look good, except for one thing. How would you handle the case where debian/control is generated from debian/control.in? dpkg-buildpackage would not be able to check for dependencies in this case, until control is generated, but you can't call debian/rules to build control until you have checked dependencies. A typical chicken/egg problem. Adam
