[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: B-D on src package? (was: Re: Challenge from Julia's non-standard vendored openblas"64_"



Hi,

Quoting Mo Zhou (2019-07-28 16:03:43)
> On 2019-07-28 13:13, Ian Jackson wrote:
> > This is maybe not directly helpful to you right now, but:
> > 
> > If we could build-depend on source packages, you could combine these
> > two ideas into something that might be less awful.
> More than once have I thought of "what if I can B-D on a source package". Is
> such demand common enough among developers?

recently there was some discussion about this in #debian-apt. I don't have the
logs of that discussion so others might want to expand on what I remember from
back then. In no particular order plus my own thoughts.

apt developers are in favour of such a feature but it would need implementation
in dpkg first. This means that dpkg would have to also track "installed"
(unpacked) source packages in /usr/src in a similar way of how it currently
tracks installed binary packages.

Tons of software that parses the Build-Depends field has to be patched. At
least: dpkg, sbuild, apt, debhelper, cdbs, pbuilder, lintian, dose3,
wanna-build, dak, devscripts, python-debian, libconfig-model-perl, augeas,
haskell-debian, dh-exec, autopkgtest...

We have to think about a good syntax for the Build-Depends field which is able
to express a build dependency on source packages unpacked to /usr/src as well
as a build dependency on the build dependencies of a certain source package for
a given host architecture. Some initial thoughts:

    Build-Depends: src:foo:src      -> src:foo unpacked in /usr/src/foo
    Build-Depends: src:foo          -> b-d of src:foo for the current host architecture
    Build-Depends: src:foo:amd64    -> b-d of src:foo for amd64
    Build-Depends: src:foo:native   -> b-d of src:foo for the current build architecture

Here, ":src" is a new suffix next to :native, :any or :${arch} indicating the
"source architecture", meaning an unpacked source package. It is also open what
a B-D on foo:src (without the src: prefix) would mean. Maybe there is a more
elegant solution.

If we choose the "src:" prefix to pick source instead of binary packages, then
it's important that we don't have any binary packages called "src" and no
source packages with a name equal to a valid debian architecture.

I think it's important to separate a dependency on the source code of src:foo
and a dependency on the build dependencies of src:foo. Sometimes one needs only
parts of src:foo and if unpacked source and its build dependencies are always
installed together, then there is no way to get one without the other.

And there has to be a syntax for how to "install" these from the command line
using apt-get.

And there is the question of whether source packages of different versions
should be installable at the same time, maybe into /usr/src/foo-${version}.

Currently we have foo-source binary packages which install their content into
/usr/src but this requires such a package to be created and there is currently
no way to get the precise build dependencies on that package.

There is also the question about build profiles. Should it be possible to only
request the build dependencies of a source package with a certain set of build
profiles active?

Are other distributions doing something similar already?

Thanks!

cheers, josch

Attachment: signature.asc
Description: signature


Reply to: