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

Bug#744246: Processed: build profiles not yet supported by debian infrastructure

I'm going to reproduce Helmut's mail to 744243 in which he asks the TC
to intervene, since it doesn't seem to have ended up on the TC list.

I'm then going to reply, doing so only to the bug report.


From: Helmut Grohne <helmut@subdivi.de>

Dear technical committe,

I ask you to find a way that enables uploading packages that make use of
build profiles[1] to the experimental archive as soon as possible. The
need for build profiles is already known for years (#661538), but it was
hard to agree on a syntax which finally happened when dpkg 1.17.2 was
uploaded to sid in December 2013.

Currently uploading Build-Profile enabled packages fails, because such
packages are rejected by dak. The immediate problem was summarized in
this bug report:

On Fri, Apr 11, 2014 at 09:12:21PM +0200, Helmut Grohne wrote:
> While trying to fix #738263, I got a REJECT:
> doxygen_1.8.6-3.dsc: APT could not parse Build-Depends field: Problem Parsing Dependency
> The Build-Depends field in question reads:
> Build-Depends: debhelper (>= 9.20140227), dpkg-dev (>= 1.17.2), libqt4-dev <!profile.stage1>, flex, bison (>= 1.875a), python, libsqlite3-dev, tmake, yui-compressor 
> It appears that this error originates from python-apt:
> >>> import apt_pkg
> >>> apt_pkg.init()
> >>> apt_pkg.parse_src_depends("foo <!profile.stage1>")
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> ValueError: Problem Parsing Dependency
> >>> 
> I believe that the latter function is used in daklib.checks to validate
> the Build-Depends line. I therefore ask you to upgrade your version of
> python-apt, to a version that correctly parses Build-Depends. In other
> words, a version of python-apt that fixes #744243.

Since filing that bug Johannes Schauer and myself talked to various
teams to address this issue ultimately leading to no progress.

 * FTP indicated that they can work with whatever DSA installs. Using a
   non-packaged copy of python-apt from jessie was considered too much
   maintenance burden.
 * DSA indicated that they only want to install software from stable or
 * SRM deemed our patches too invasive. Thread starts at:
 * backports indicated that the patches are against the backports

While each team's members were constructive at all times and their
reasons are reasonable, the result is that build profiles do not work

Given the above, I ask CTTE to find a constructive way allows uploading
Build-Profile enabled packages to experimental (or even sid).


[1] https://wiki.debian.org/BuildProfileSpec

Reply to: