Re: Profile support in apt
On Tue, Jan 29, 2013 at 6:37 PM, Johannes Schauer <j.schauer@email.de> wrote:
> On Tue, Jan 29, 2013 at 07:55:20AM +0800, Daniel Hartwig wrote:
>> On 29 January 2013 01:47, Wookey <wookey@wookware.org> wrote:
>> > If apt honours DEB_BUILD_PROFILE=foo then sbuild (which already has a
>> > patch to set this) just sets it and everything should 'just work' (we
>> > already have dpkg patches to make it DTRT).
>> >
>> > So, pointers as to which files/functions I should be looking at are
>> > what this post hopes to elicit, although of course patches showing
>> > just how trivial it is, would be even better :-)
>>
>> Frontend: cmdline/apt-get.cc (DoBuildDeps).
>>
>> Backend: apt-pkg/deb/debsrcparser.cc (BuildDepends),
>> apt-pkg/deb/deblistparser.cc (ParseDepends).
>>
>> Please check for the envvar in the frontend rather than the backend.
>
> I hacked together a simple patch that just touches ParseDepends and
> heavily borrows from the logic which parses architecture lists.
>
> As wookey already pointed out it would be nice if apt could understand
> the environment variable DEB_BUILD_PROFILE. But the only environment
> variable apt currently uses is APT_CONFIG.
Expect the myriad of environment settings which need to be parsed
for support of each and every possible language setup [I know of].
(apt-pkg/aptconfiguration.cc – APT::Configuration::getLanguages)
I would go with a similar setup here, just less complicated by taking
the first thing which exists:
- APT::Build-Profile "foo,bar";
- APT::Build-Profile { "foo"; "bar"; };
- DEB_BUILD_PROFILE=foo,bar
Maybe go fancy in supporting a special "environment" name which
extends to whatever is in the environment variable, so you could do
silly configs like APT::Build-Profile { "nodocs"; "environment"; } and
DEB_BUILD_PROFILE="cross" apt-config dump APT::Build-Profile
would produce: APT::Build-Profile { "nodocs"; "cross"; };
(I just used "environment" here as it is used by languages – it is just
to unlikely to be a valid language code – use whatever fits best)
I think I would be against including the environment always in the list
as it is against how the other lists are handled, yet, there are only
two (Acquire::Languages, APT::Architectures) and both are from me,
so I might be biased (and others like Acquire::CompressionTypes
behaves a bit differently too, so just choose something which fits and
write some documentation to convince everyone).
> variable. Also, a profile is always selected on a per-package basis and
> will never (and should never) be set globally.
I guess it is in case of crossbuilding or for bootstrapping, but if this
is ever extended to profiles like "nodocs" or "nocheck" this could easily
become a global setting for some usecases.
Having it as a option can help also in cases in which it is at least
inconvenient to set a environment variable before calling an executable
(and in case you want an own command-line flag its a hard-requirement).
Oh, and with APT::Build-Profile I just follow Julians suggestion, given that
aptitude supports "build-dep", too, it would be harsh to move it in APT::Get
namespace (not just aptitude, there are other apt-* tools which deal with
sources and building them – might be useful for e.g. apt-build).
I don't know what these tools use to parse dependencies though so
more code which must not be included in ParseDepends directly probably
means that it is better for everyone.
>From an implementation point of view of the profiles itself I guess you can
reuse the boolean ParseArchFlags from ParseDepends. It's not like we
would support architecture wildcards in non-build-dependencies, nor that
we want to for now (just think of all the kittens trying to crossgrade) and
adding yet another flag just makes it more visible that this code needs
an overhaul in the longrun …
Yet, I haven't seen the final syntax yet, just various proposals so be
prepared that at least I will be not in favor of merging something which
isn't supported in an uploaded mainline-debian dpkg yet – and feedback
might be sparse for the moment as we have still items open for wheezy
so jessie topics might not be that interesting just yet.
Best regards
David Kalnischkies
Reply to: