suggestion: build-blockers field in control file
 

Some packages have runtime dependencies on packages that they do not
have corresponding build-dependencies for. This leads to the building of
uninstallable packages which in turn leads to problems with testing
transition of packages.


Currently there are two workarounds for this situation

1: manually alter the package's architecture list to limit building to
those architectures where runtime dependencis

2: add an artificial build-dependency

Neither is ideal, the first must be manually undone if and when the
dependencies do become available. The second is an abuse of the
build-depends field (the package isn't REALLY needed for building) and
causes pacakges to be unnessacerally installed in build environments
(both on autobuilders and for those manually building the package)
wasting time and network bandwidth.


I therefore propose a new control field for source packages
"build-blockers". Autobuilder management systems should generally treat
build-blockers the same as build-depends but the systems that actually
do the building do not need to take any notice of them.


What do others think?


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4ED5314B.1070800@p10link.net">http://lists.debian.org/4ED5314B.1070800@p10link.net

suggestion: build-blockers field in control file
 

peter green wrote:

[...]
> This leads to the building of
> uninstallable packages which in turn leads to problems with testing
> transition of packages.
>
> Currently there are two workarounds for this situation
>
> 1: manually alter the package's architecture list to limit building to those
> architectures where runtime dependencis
> 2: add an artificial build-dependency

For completeness, it's probably worth mentioning a third option:

3: use the architecture list to document fundamental portability hurdles
and packages-arch-specific[*] to document accidental ones
[*] http://www.debian.org/doc/manuals/developers-reference/pkgs.html.en#packages-arch-specific


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111129200854.GA9450@elie.hsd1.il.comcast.net">ht tp://lists.debian.org/20111129200854.GA9450@elie.hsd1.il.comcast.net

suggestion: build-blockers field in control file
 

* peter green <plugwash@p10link.net>, 2011-11-29, 19:23:
Some packages have runtime dependencies on packages that they do not
have corresponding build-dependencies for. This leads to the building
of uninstallable packages which in turn leads to problems with
testing transition of packages.


Currently there are two workarounds for this situation

1: manually alter the package's architecture list to limit building
to those architectures where runtime dependencis

2: add an artificial build-dependency

Neither is ideal, the first must be manually undone if and when the
dependencies do become available. The second is an abuse of the
build-depends field (the package isn't REALLY needed for building)
and causes pacakges to be unnessacerally installed in build
environments (both on autobuilders and for those manually building
the package) wasting time and network bandwidth.


I therefore propose a new control field for source packages
"build-blockers". Autobuilder management systems should generally
treat build-blockers the same as build-depends but the systems that
actually do the building do not need to take any notice of them.


It doesn't sound completely crazy, but I doubt that implementing such
field is worth the trouble. How many packages would benefit from it? Do
you have any concrete examples?


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111201153020.GB4568@jwilk.net">http://lists.debian.org/20111201153020.GB4568@jwilk.net

suggestion: build-blockers field in control file
 

On Wed, 30 Nov 2011, peter green <plugwash@p10link.net> wrote:
> Some packages have runtime dependencies on packages that they do not
> have corresponding build-dependencies for. This leads to the building of
> uninstallable packages which in turn leads to problems with testing
> transition of packages.
>
> Currently there are two workarounds for this situation
>
> 1: manually alter the package's architecture list to limit building to
> those architectures where runtime dependencis
> 2: add an artificial build-dependency

Why are such things required?

Why not have software which wants to have the dependencies of a package look
at the dependencies line as well as the build-dependencies?

It seems to me that the package maintainers are already providing the
necessary information and the people who maintain autobuilder systems just
need to use it.

I can't imagine that changing lots of packages and keeping track of new
packages with similar issues would take less work than changing an
autobuilder. I also can't imagine that changing lots of packages would be as
reliable.

--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201112021230.36184.russell@coker.com.au">http://lists.debian.org/201112021230.36184.russell@coker.com.au

suggestion: build-blockers field in control file
 

[Russell Coker]
> Why not have software which wants to have the dependencies of a
> package look at the dependencies line as well as the
> build-dependencies?
>
> It seems to me that the package maintainers are already providing the
> necessary information and the people who maintain autobuilder systems
> just need to use it.

Hmmmm. Do you mean:

(1) The buildd should parse debian/control prior to building, and
delay the build ("dep-wait") if any binary package Depends line
would not (yet) be satisfied?

(2) The buildd should not upload a build until every binary package
in the built .changes file is installable?

(3) The buildd should edit the .changes file to exclude binary
packages that are not installable, upload _that_, then put the rest
of the binary packages in some sort of hold queue?

(4) ???

(1) is problematic for several reasons; most specifically, that it is
possible, and even common, for not every package in debian/control to
be built on every architecture. You can't predict which packages will
actually be built.

(2) is less problematic, but does introduce extra delay into package
build and propagation. It also would require manual intervention for
any dependency loop.

And (3) seems like a very complex workflow to solve a very small problem.

--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111202081023.GA3939@p12n.org">http://lists.debian.org/20111202081023.GA3939@p12n.org