Re: Profile support in apt
On 30 January 2013 05:40, David Kalnischkies
<kalnischkies+debian@gmail.com> wrote:
> 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:
> 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
This looks like a sensible way to go.
>> variable. Also, a profile is always selected on a per-package basis and
>> will never (and should never) be set globally.
> 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).
For single-run command line tools this should not be a problem either
way. For the benefit of maintaining consistency in APT, the canonical
location should be _config. If supporting the environment variable,
it should be loaded during apt init so that all tools consistently
support it.
I am not aware of any interactive programs that support build-depends
(aptitude does only from the command line). If there was such a
program, it would have to present an interface for selecting the
profile and can change this config. setting on demand. Though this
requires some way to know the list of profiles, which requires reading
and filtering build dependencies to be distinct functions.
> 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
The choice of namespace depends on which side makes the decision to
filter. If libapt will do this filtering automatically, it certainly
belongs in the APT:: namespace. If the frontend must invoke a
function to filter the list of build depends it receives, then it is
ok for APT::Get namespace (in this case, other frontends such as
aptitude will configure the option separately, in their own
namespace).
> 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.
Aptitude uses pkgSrcRecords::Parser. It would be useful to both its
interactive and command line modes to have access to build profile
settings of each dependency.
For maximum utility, libapt clients must be able to access the profile
data. It is also convenient for all libapt clients to support this
universally with minimal effort, by changing the existing interface to
filter. Perhaps this can be handled by:
- extending (or deriving from) BuildDepRec to store the profile data;
- move the bulk of debSrcRecordParser::BuildDepends to a new function
for reading *all* the build dependency information;
- implement a new function to filter the list it returns based on
either config. option or explicit argument; and
- refactor ::BuildDepends as a wrapper around the two other functions.
Effectively, the current behaviour is to select an implicit default
build profile. In that view, existing programs using the
::BuildDepends interface will not change their semantics, yet will
support whatever profile has been specified. Other programs can take
advantage of the new interfaces to provide more informative
interfaces.
Regards
Reply to: