Your message dated Sun, 24 Feb 2019 02:15:27 +0100
with message-id <20190224011527.ga8...@gaara.hadrons.org>
and subject line Re: Bug#360643: APT configure flags
has caused the Debian Bug report #360643,
regarding Support build configuration flags (a la FreeBSD/Gentoo)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
360643: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=360643
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: APT.
Version: any.

For a truly powerfull system, the ability to configure one's packages is crucial.
APT lacks this feature.
To extend APT, the DEB format should be extended with a configure flag field, similar to Gentoo, and all packages should specify their dependencies. Official packages will be supported for the flags chosen by the developers, but unofficial packages should be easier to build than they are today, through a make.conf/mk.conf system.

Example:
Xfwm4 could have the following flags: xml, svg, png, composite, which would turn
on configure options. The official DEB could have xml and png turned on.
But the simple existence of this field could allow automation of builds.

The system is not new, it's being used on FreeBSD/NetBSD and Gentoo (and many others).

The beginning would be extending the DEB format, and shouldn't require any significant
overhead, except for ignoring the new field when it's not required.
Later down the road, a tool such apt-build could be extended to provide aditional functionality, activating configure flags, as does portage, or ports, or pkgsrc.




--- End Message ---
--- Begin Message ---
Version: 1.17.2

Hi!

On Mon, 2006-04-03 at 22:23:50 +0300, Oblio wrote:
> For a truly powerfull system, the ability to configure one's packages is
> crucial.
> APT lacks this feature.
> To extend APT, the DEB format should be extended with a configure flag
> field, similar
> to Gentoo, and all packages should specify their dependencies. Official
> packages
> will be supported for the flags chosen by the developers, but unofficial
> packages
> should be easier to build than they are today, through a make.conf/mk.conf
> system.
> 
> Example:
> Xfwm4 could have the following flags: xml, svg, png, composite, which would
> turn
> on configure options. The official DEB could have xml and png turned on.
> But the simple existence of this field could allow automation of builds.
> 
> The system is not new, it's being used on FreeBSD/NetBSD and Gentoo (and
> many others).
> 
> The beginning would be extending the DEB format, and shouldn't require any
> significant
> overhead, except for ignoring the new field when it's not required.
> Later down the road, a tool such apt-build could be extended to provide
> aditional
> functionality, activating configure flags, as does portage, or ports, or
> pkgsrc.

The essence of this got implemented in dpkg 1.17.2 in the shape of
build profiles. Here's the relevant changelog entry:

,---
dpkg (1.17.2) unstable; urgency=low

  [ Guillem Jover ]
  …
  * Add experimental build profiles support:
    - Add support for <!profile.name> build-time restrictions in dependencies.
    - Add support for DEB_BUILD_PROFILES environment variable.
    - Add new option -P to dpkg-buildpackage and dpkg-checkbuilddeps.
    - Add new Built-For-Profiles output field in .deb and .changes files.
    Based on a patch by Patrick "P. J." McDermott <p...@nac.net>,
    Wookey <woo...@debian.org> and Johannes Schauer <j.scha...@email.de>.
    Closes: #661538
  …

 -- Guillem Jover <guil...@debian.org>  Thu, 05 Dec 2013 04:56:31 +0100
`---

For more information you can check also
<https://wiki.debian.org/BuildProfileSpec>. Closing this now.

Thanks,
Guillem

--- End Message ---

Reply via email to