Bug#886238: Build-Profiles purpose, mechanism vs policy (was Re: Bug#886238: Please introduce official nosystemd build profile)

[Guillem Jover]

On Thu, 2018-01-18 at 18:52:57 +0100, Emilio Pozuelo Monfort wrote:
> On 10/01/18 01:29, Sam Hartman wrote:
> > A build profile seems like a great way to express the flag, and like
> > many things in Debian, the work would fall on those who would benefit
> > from it.
> 
> I think it'd be better to be able to mark a build-dependency as optional, and
> then implement a mechanism in dpkg to disable the undesired 
> build-dependencies.
> E.g. if packages start marking libselinux-dev as , with autoconf or
> similar automatically disabling selinux support when not present, then a user
> could build the package with something like dpkg-buildpackage
> --disable-optional=libselinux-dev.

That assumes that the package can and should be removed for this to
work at all, which does not hold when some transitive package has a
hard requirement on it, functionality which might or might not be
exposed at run-time, say when needed also for a tool built and used
only during the build. This also ties specific functionality to
specific package names, I think defining a build-profile is superior
because it can include groups of related packages exposing the same
functionality. This also covers only part of what build-profiles
provides, only full disablement, which requires thus full marking
of all the build-depency chain.

I think this alone makes this unreliable and less useful.

> This way we don't need a different build profile for each build-dep and
> package, which would end up in a mess. Of course we need to change the
> above syntax to not clash with build profiles, and add DEB_BUILD_OPTIONS
> support, but you get the point I hope. Seems a lot more standard to me
> than having each package define its own profiles for each optional
> dependency.

We'd still need to mark those packages anyway. We also have a registry
and namespaces for a reason, so that we do not get into a mess. :)

Iff we wanted to implement this package-specific disablement marking,
that part can already be implemented using build-profiles w/o needing
to invent some new syntax, fixing all parsers and deploying the change,
etc., which seems rather suboptimal. Something like this could do, f.ex.:

  libselinux-dev 

Obviously it has the drawbacks that it duplicates the package name, and
the way the name is used here can be confusing, but at least the last
point is _just_ a matter of finding a better name for the namespace. OTOH
it can be used right now (after agreeing on the namespaces, iff this
seems worthwhile at all, etc.).

But, I don't see this as a very convincing solution TBH.

Or, we could just keep adding the current nofoo-style profiles we have
been registering, whenever the need arises.

Also I'm not sure what you mean by "more standard" though, because what
we come up with can be as standard as we make of it? :)

Thanks,
Guillem

Bug#886238: Build-Profiles purpose, mechanism vs policy (was Re: Bug#886238: Please introduce official nosystemd build profile)

[Sam Hartman]

> "Adrian" == Adrian Bunk  writes:


Adrian> For many use flags the only benefit is an unused library
Adrian> less on the system when the flag is disabled, and this also
Adrian> applies to the proposed nosystemd profile discussed in this
Adrian> bug.

Agreed.

Adrian> Support for nosystemd in only 95% of all libsystemd-using
Adrian> packages would still result in libsystemd being installed -
Adrian> if just one maintainer would refuse to apply a nosystemd
Adrian> patch, the people working on nosystemd in Debian basically
Adrian> have to rely on CTTE overruling the maintainer.

I disagree with this.
First, that's only true if the package in question is essential, or if
the user needs to install the package in question.

In a world where users never modify, patch or rebuild source you're
absolutely right that this only provides utility if you get 100%
coverage.

users include organizations that are willing to rebuild packages
(patching them if necessary) to meet regulatory, security, or other
requirements.  Users also include downstream distributions and their
users who  are willing to patch software.

In this world, there is siginificant utility to minimizing the number of
patches users apply.
95% coverage would be much easier to deal with than no support at all.

I feel fairly strongly about this because I have been that downstream.
I've been in situations where I was trying to get some feature into
Debian or another project.  I suspect my future includes a fair number
of cases where the future I care about involves being able to build
without some feature because doing so makes regulatory accreditation
much easier for me.

Perhaps it's not worth Debian's time to work with me.
However I'm frustrated when you claim that this only has utility to me
when Debian gets 100% coverage: minimizing divergence has real value.
Does it have enough value to justify some change to Debian?  I think we
should consider that on a case by case basis like we always do.


In the particular case of systemd, I don't have any interest in working
to make it easier to build on Linux without libsystemd installed.  I'd
probably accept patches that did not significantly increase the
complexity of my packages if they did that, but would not go write such
patches.

Bug#886238: Build-Profiles purpose, mechanism vs policy (was Re: Bug#886238: Please introduce official nosystemd build profile)

[Emilio Pozuelo Monfort]

On 18/01/18 21:50, Adrian Bunk wrote:
> On Thu, Jan 18, 2018 at 06:52:57PM +0100, Emilio Pozuelo Monfort wrote:
>> On 10/01/18 01:29, Sam Hartman wrote:
>>> A build profile seems like a great way to express the flag, and like
>>> many things in Debian, the work would fall on those who would benefit
>>> from it.
>>
>> I think it'd be better to be able to mark a build-dependency as optional, and
>> then implement a mechanism in dpkg to disable the undesired 
>> build-dependencies.
>> E.g. if packages start marking libselinux-dev as , with autoconf or
>> similar automatically disabling selinux support when not present, then a user
>> could build the package with something like dpkg-buildpackage
>> --disable-optional=libselinux-dev. This way we don't need a different build
>> profile for each build-dep and package, which would end up in a mess. Of 
>> course
>> we need to change the above syntax to not clash with build profiles, and add
>> DEB_BUILD_OPTIONS support, but you get the point I hope. Seems a lot more
>> standard to me than having each package define its own profiles for each
>> optional dependency.
> 
> When the sole purpose of a rebuild is to get rid of unused library(ies),
> the rebuild only makes sense if this is supported throughout the whole
> distribution.
> 
> The problematic cases are the non-trivial ones,
> and what support Debian wants to provide for that.
> 
> It would make the life for the Devuan people much easier if Debian
> would be committed to have *all* packages in buster build and work
> with --disable-optional=libsystemd-dev.
> 
> Are you as release manager willing to make this a supported feature
> for buster, with breakages being RC bugs?
> 
> For small embedded systems, having this only for one library
> doesn't bring that many benefits.
> 
> For how many libraries are you release manager willing to make 
> --disable-optional a supported feature for buster, with breakages
> being RC bugs?

Nothing of this sort is going to be RC, no matter if we implement it via build
profiles or by some other mechanism. I'm not even sure we need it. My only point
is that if we are going to start adding this for every optional feature as it
was being suggested, we should do it properly and not abusing build profiles.

Cheers,
Emilio

Bug#886238: Build-Profiles purpose, mechanism vs policy (was Re: Bug#886238: Please introduce official nosystemd build profile)

[Adrian Bunk]

On Thu, Jan 18, 2018 at 06:52:57PM +0100, Emilio Pozuelo Monfort wrote:
> On 10/01/18 01:29, Sam Hartman wrote:
> > A build profile seems like a great way to express the flag, and like
> > many things in Debian, the work would fall on those who would benefit
> > from it.
> 
> I think it'd be better to be able to mark a build-dependency as optional, and
> then implement a mechanism in dpkg to disable the undesired 
> build-dependencies.
> E.g. if packages start marking libselinux-dev as , with autoconf or
> similar automatically disabling selinux support when not present, then a user
> could build the package with something like dpkg-buildpackage
> --disable-optional=libselinux-dev. This way we don't need a different build
> profile for each build-dep and package, which would end up in a mess. Of 
> course
> we need to change the above syntax to not clash with build profiles, and add
> DEB_BUILD_OPTIONS support, but you get the point I hope. Seems a lot more
> standard to me than having each package define its own profiles for each
> optional dependency.

When the sole purpose of a rebuild is to get rid of unused library(ies),
the rebuild only makes sense if this is supported throughout the whole
distribution.

The problematic cases are the non-trivial ones,
and what support Debian wants to provide for that.

It would make the life for the Devuan people much easier if Debian
would be committed to have *all* packages in buster build and work
with --disable-optional=libsystemd-dev.

Are you as release manager willing to make this a supported feature
for buster, with breakages being RC bugs?

For small embedded systems, having this only for one library
doesn't bring that many benefits.

For how many libraries are you release manager willing to make 
--disable-optional a supported feature for buster, with breakages
being RC bugs?

It is really important to look at it top-down from what Debian
wants to officially support in the end - these technical details
only matter if Debian will officially support rebuilding the
whole archive of a stable release with fewer libraries.

> Cheers,
> Emilio

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#886238: Build-Profiles purpose, mechanism vs policy (was Re: Bug#886238: Please introduce official nosystemd build profile)

[Don Armstrong]

On Thu, 18 Jan 2018, Emilio Pozuelo Monfort wrote:
> I think it'd be better to be able to mark a build-dependency as
> optional, and then implement a mechanism in dpkg to disable the
> undesired build-dependencies.

Someone who was interested could get part way to this by running builds
with an empty equivs package which satisfied the build-dependency.

That could help give the involved parties (which does not include me) an
idea of whether implementing such a feature was a worthwhile expenditure
of their energy.

-- 
Don Armstrong  https://www.donarmstrong.com

He no longer wished to be dead. At the same time, it cannot be said
that he was glad to be alive. But at least he did not resent it. He
was alive, and the stubbornness of this fact had little by little
begun to fascinate him -- as if he had managed to outlive himself, as
if he were somehow living a posthumous life.
 -- Paul Auster _City of Glass_

Bug#886238: Build-Profiles purpose, mechanism vs policy (was Re: Bug#886238: Please introduce official nosystemd build profile)

[Emilio Pozuelo Monfort]

On 10/01/18 01:29, Sam Hartman wrote:
> A build profile seems like a great way to express the flag, and like
> many things in Debian, the work would fall on those who would benefit
> from it.

I think it'd be better to be able to mark a build-dependency as optional, and
then implement a mechanism in dpkg to disable the undesired build-dependencies.
E.g. if packages start marking libselinux-dev as , with autoconf or
similar automatically disabling selinux support when not present, then a user
could build the package with something like dpkg-buildpackage
--disable-optional=libselinux-dev. This way we don't need a different build
profile for each build-dep and package, which would end up in a mess. Of course
we need to change the above syntax to not clash with build profiles, and add
DEB_BUILD_OPTIONS support, but you get the point I hope. Seems a lot more
standard to me than having each package define its own profiles for each
optional dependency.

Cheers,
Emilio

Bug#886238: Build-Profiles purpose, mechanism vs policy (was Re: Bug#886238: Please introduce official nosystemd build profile)

[Bastian Blank]

On Tue, Jan 09, 2018 at 07:29:51PM -0500, Sam Hartman wrote:
> A build profile seems like a great way to express the flag, and like
> many things in Debian, the work would fall on those who would benefit
> from it.
> So, I do support the use of build profiles for use flags.
> I also believe there's sufficient utility for downstreams and users to
> justify this.

Okay.  As you think they are worth to think about: Please take one such
a flag; provide a description what it should do, both for the user and
on the system level; describe both the advantages and the drawbacks.
Oh, and please provide a list of packages you would start with applying
this change.

Bastian

-- 
Suffocating together ... would create heroic camaraderie.
-- Khan Noonian Singh, "Space Seed", stardate 3142.8

Bug#886238: Build-Profiles purpose, mechanism vs policy (was Re: Bug#886238: Please introduce official nosystemd build profile)

[Adrian Bunk]

On Tue, Jan 09, 2018 at 07:29:51PM -0500, Sam Hartman wrote:
> > "Adrian" == Adrian Bunk  writes:
> 
> Adrian> On Tue, Jan 09, 2018 at 01:23:32PM +0100, Guillem Jover wrote:
> >> ...  Given the background of build-profiles, I'm very much in
> >> favor of introducing the equivalent usage as Gentoo USE flags,
> >> which was its main intention! :) It could make Debian a viable
> >> source-based distribution to use or base on, could make many of
> >> the embedded specific distribution solutions obsolete, ...
> 
> Adrian> Who would then implement, maintain and support this in all
> Adrian> packages?
> 
> No one.  People would implement and test the feature where it was
> sufficiently useful to implement and test.  I don't think all of the use
> flags combinations are tested in source distributions that have them
> today.
>
> Even so, users find those flags useful enough to spend a fair bit of
> work on them.

To "make many of the embedded specific distribution solutions obsolete",
Debian would have to provide all this in stable releases at a quality
comparable to Yocto.

> A build profile seems like a great way to express the flag, and like
> many things in Debian, the work would fall on those who would benefit
> from it.
> 
> So, I do support the use of build profiles for use flags.
> I also believe there's sufficient utility for downstreams and users to
> justify this.

For many use flags the only benefit is an unused library less on
the system when the flag is disabled, and this also applies to the
proposed nosystemd profile discussed in this bug.

Support for nosystemd in only 95% of all libsystemd-using packages would
still result in libsystemd being installed - if just one maintainer 
would refuse to apply a nosystemd patch, the people working on nosystemd
in Debian basically have to rely on CTTE overruling the maintainer.


Your "build profiles for use flags" can easily require changes to 
hundreds of packages just for one flag, often including non-trivial 
changes to e.g. debian/rules or .install files.

This only makes sense if there is consensus that this is a useful
direction, and that this should be fully supported in future stable
releases of Debian.


> --Sam

cu
Adrian

[1] Raspberry Pi Zero is already big enough to not require use flags

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Storing build profiles in binary packages (was: Re: Bug#886238: Please introduce official nosystemd build profile)

[Guillem Jover]

[ Just few comments to complement josch's veyr nice reply, with which I
  completely agree with. ]

On Thu, 2018-01-11 at 00:47:28 +0100, Johannes Schauer wrote:
> Quoting Steve Langasek (2018-01-10 21:49:02)
> > As a policy, I think it's clear that packages built with non-default 
> > profiles
> > should never be included in the Debian archive;
> 
> Why? By enforcing (via a policy and checkable via reproducible builds) that 
> the
> binary packages that are being built with one (possibly empty) set of build
> profiles active are bit-by-bit identical to those built with a different set 
> of
> build profiles active, it doesn't matter whether a given binary package was
> built with either set.

Yes, and in addition this information is recorded in both .changes
and .buildinfo files. I was initially among the ones wanting this
information in the .debs to be able to trace it, but the need
disappeared when we introduced .buildinfo files, because then we've
got the upload specific recording for the archive processor (.changes),
and the supposedly public facing record of what was done during the
build (.buildinfo), although the later can never be fully trusted
anyway. :)

> > and segregating packages into archives by stage is a sensible way to do this
> > for bootstrapping.
> 
> We don't want "stages" for bootstrapping. This is also why the "stage1" and
> "stage2" build profiles are marked as "deprecated" on the wiki page. Those
> profile names are only used by toolchain packages for reasons that go beyond
> the scope of this thread. The reason we don't want "stageX" profiles but
> instead nofoo profiles (disabling foo) are:
> 
>  - dependency relationships change regularly. Thus, what is a stage1 today
>might not even be needed for bootstrapping anymore tomorrow. But the 
> profile
>might have other uses, for example by downstreams.
> 
>  - dependency relationships change regularly. Thus the notion of what a
>"stage1" build of a package is also changes regularly. At some point, the
>state of the archive might require a source package to be built without
>libfoo-dev and without libbar-dev. At another point in time, it is
>sufficient to build the source package only without libfoo-dev. At another
>point, it would make sense to build it without libfoo-dev and also without
>libbaz-dev. If there are separate profiles for foo, bar and baz, then an
>automated machinery can exactly choose how to build source packages.
> 
>  - the functionality removed or changed by a stageX profile might overlap with
>another profile name that is needed for a purpose that is not bootstrapping
>(for example by a downstream). Then, in all places where this functionality
>is activated or deactivated, the full list of profiles that touch it must 
> be
>repeatedly enumerated. It is easier to maintain a single build profile that
>is directly connected with exactly that functionality.  See my argument
>about maintainability of build profiles for each distribution in [1].
> 
> [1] https://lists.debian.org/151553652380.1442.14816198615195092481@localhost

The take home here is that, stages do not scale, they might be fine for
just a toolchain perhaps, but not to automatically bootstrap the entire
build-essential set, or automatically bootstrap dependency cycles.

> > I don't know /what/ one should expect in a world where profiles are used for
> > other purposes but aren't documented in the binary control; I guess it just
> > reinforces the fact that you can't trust third-party deb packages...
> 
> With respect to dependencies you already could not trust third-party deb
> packages. In that sense, a binary package built by a third party with a 
> certain
> build profile active is no different than that third party building the same
> source package without build profiles but with an unknown configuration of the
> build system, for example.

Exactly. Or built with build profiles but the field removed afterwards,
or any other number of changes. Anything that lies outside the confines
of a specific distribution can never be fully trusted within that
distribution.

Thanks,
Guillem

Storing build profiles in binary packages (was: Re: Bug#886238: Please introduce official nosystemd build profile)

[Johannes Schauer]

Quoting Steve Langasek (2018-01-10 21:49:02)
> On Mon, Jan 08, 2018 at 08:36:50PM -0500, Michael Stone wrote:
> > On Mon, Jan 08, 2018 at 12:09:09PM -0800, Steve Langasek wrote:
> > > Top-posting to just say +1, and that I was going to reply with much the
> > > same.
> 
> > > I don't even think the requirement for the bootstrap profiles to not
> > > functionally change the packages is necessary, but it's the way the folks
> > > working on bootstrappability have chosen to do it, so it's their call.  
> > > But
> > > that's definitely not a binding precedent on other build profiles that 
> > > might
> > > be implemented.
> 
> > How, then, would you tell by looking at the package name+version which kind
> > of package you have? If you're going to change the name or version string
> > anyway, why use some complicated profile system instead of just applying a
> > patch? This seems overly complicated for simple cases and overly fragile for
> > complex cases.
> 
> The fact that this information is no longer exposed in the binary control
> file is news to me, and very disappointing.  It seems clear to me that one
> *should* be able to determine what profile(s) a package was built with by
> looking at the package itself.

Why?

Picture two binary packages with the same name/version/arch tuple, they were
maybe even built by the exact same source package but they were built on
different distributions (or at different times with some build dependencies
having changed) so their contents differ. Even today we are not storing the
information on which platform a source package was built in binary packages. We
only expect binary packages with the same name/version/arch from the same
distribution to play well with each other. And that distribution controls the
build profiles it builds binary packages with. What makes build profiles so
different when you compare it with other factors that change binary package
content? We are also not storing that information in binary packages. But we
have a place to store that information: buildinfo files. Those files also store
with which build profiles a source package was built.

I only see one reason for which one could want to store with which build
profile a package was built in the binary package itself: if that information
becomes relevant for dependency resolution.

Though I guess for downstreams who want to have the Build-Profiles field in the
binary packages they build, I guess there could be a solution involving dpkg
vendors.

> As a policy, I think it's clear that packages built with non-default profiles
> should never be included in the Debian archive;

Why? By enforcing (via a policy and checkable via reproducible builds) that the
binary packages that are being built with one (possibly empty) set of build
profiles active are bit-by-bit identical to those built with a different set of
build profiles active, it doesn't matter whether a given binary package was
built with either set.

> and segregating packages into archives by stage is a sensible way to do this
> for bootstrapping.

We don't want "stages" for bootstrapping. This is also why the "stage1" and
"stage2" build profiles are marked as "deprecated" on the wiki page. Those
profile names are only used by toolchain packages for reasons that go beyond
the scope of this thread. The reason we don't want "stageX" profiles but
instead nofoo profiles (disabling foo) are:

 - dependency relationships change regularly. Thus, what is a stage1 today
   might not even be needed for bootstrapping anymore tomorrow. But the profile
   might have other uses, for example by downstreams.

 - dependency relationships change regularly. Thus the notion of what a
   "stage1" build of a package is also changes regularly. At some point, the
   state of the archive might require a source package to be built without
   libfoo-dev and without libbar-dev. At another point in time, it is
   sufficient to build the source package only without libfoo-dev. At another
   point, it would make sense to build it without libfoo-dev and also without
   libbaz-dev. If there are separate profiles for foo, bar and baz, then an
   automated machinery can exactly choose how to build source packages.

 - the functionality removed or changed by a stageX profile might overlap with
   another profile name that is needed for a purpose that is not bootstrapping
   (for example by a downstream). Then, in all places where this functionality
   is activated or deactivated, the full list of profiles that touch it must be
   repeatedly enumerated. It is easier to maintain a single build profile that
   is directly connected with exactly that functionality.  See my argument
   about maintainability of build profiles for each distribution in [1].

[1] https://lists.debian.org/151553652380.1442.14816198615195092481@localhost

> I don't know /what/ one should expect in a world where profiles are used for
> other purposes but aren't documented in the binary control; I guess it 

Re: (was: Re: Bug#886238: Please introduce official nosystemd build profile)

[Johannes Schauer]

Hi,

Quoting Steve Langasek (2018-01-10 21:52:44)
> On Tue, Jan 09, 2018 at 03:07:01PM +0100, Johannes Schauer wrote:
> > Such a header could be introduced but that would be undesirable for two
> > reasons:
> 
> >  - it would make it hard to check whether the binary packages a source 
> > package
> >produces are really not different with a certain build profile active. 
> > Right
> >now, because of the lack of such a header, we can use the tools from the
> >reproducible builds project to verify that a build profile does not 
> > tamper
> >with package contents
> 
> >  - right now, a package is uniquely defined by dependency solvers through 
> > their
> >the name/version/architecture tuple. It would be possible to make this a
> >quadruplet and let packages be unique by their
> >name/version/architecture/profile property but that would require massive
> >changes in even more parts of our infrastructure than the introduction of
> >build profiles already required.
> 
> I think this is an unfortunate case of designing the solution to fit the
> particular set of tools.
> 
> Build profiles, as a general thing (which they are supposed to be - this is
> a major reason support took as long to land in dpkg as it did!), are
> significantly less usable if the build profile doesn't follow the resulting
> .deb as a tag.

Right now, the big difference between build profiles and Gentoo USE flags is,
that build profiles only work for source packages. In contrast to USE flags, it
is (currently) impossible to declare dependencies on binary packages built with
a certain set of build profiles active (or not active). The current crutch we
employ is to make use of the binary package name. By building binary packages
with different names when certain profiles are activated we can use our
existing dependency system.

Our current solution to build profiles does not forbid any future development
that extends the uniqueness of binary packages from name/version/arch to
name/version/arch/profile and introduces a new syntax that allows dependencies
on binary packages with a certain set of profiles activated or deactivated.
This is possible with Gentoo USE flags.

So if we ever decide that we want to make Debian more of a source distribution
and pull a full Gentoo, then we can:

 - come up with a nice syntax for binary package dependencies
 - modify all tools involved in dependency resolution accordingly
 - add the Build-Profiles field to all generated binary packages

If the project at some point in the future decides that this shall be the way
to go, then I shall not stand in the way of such a development. I don't think
that the current way that build profiles work maneuvered us into a dead end if
you have such a future in mind.

But unless we want to pull a full Gentoo here and really make the information
with which build profile a given binary package was built part of the binary
package and thus overhaul all our dependency resolvers, unless the plan is to
do that, I don't see why binary packages should contain this information.

Either it is used for dependency resolution and then we should have the field
or it isn't and then the field is rather making things like comparing packages
with each other difficult. We already accept that the uniqueness of packages
with respect to their name/version/arch only holds within a certain
distribution. But that distribution will also always know with which build
profiles they built all their packages.

So I'm still not convinced.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#886238: Build-Profiles purpose, mechanism vs policy (was Re: Bug#886238: Please introduce official nosystemd build profile)

[Steve Langasek]

On Tue, Jan 09, 2018 at 01:23:32PM +0100, Guillem Jover wrote:
> On Mon, 2018-01-08 at 18:37:11 +, Wookey wrote:
> > On 2018-01-03 13:30 +, Simon McVittie wrote:
> > > On Wed, 03 Jan 2018 at 15:12:51 +0300, Hleb Valoshka wrote:
> > > > Please introduce official nosystemd build profile so downstream
> > > > distributions can send patches to package maintainers with
> > > > systemd-less build instead of keep them in home.

> > > In general, build profiles are not meant
> > > to result in functional changes to packages
> > > (),

> > This is correct for the mechanism's main/original purpose of
> > bootstrapping/removing cyclic dependencies.  The idea is that you
> > can't change functionality and still use a dependency with the same
> > name, if you actually want to automate the bootstrap process (because
> > you don't know which features of a package the depending-on package
> > uses).

> Exactly, pretty much because otherwise doing automatic bootstrapping
> (reusing existing package names and dependency relationships) becomes
> either very hard or impossible to handle or reason about.

So, the folks who are working on bootstrappability have made their decision
about the semantics of these profiles, and those that do the work get to
decide, and all that.  But I don't agree that there's anything difficult to
reason about here.

The sole requirement that a stage1 package *must* fulfill is that it's
usable for bootstrapping any stage2 packages that require this package (or,
if no such stage2 packages exist, then "final" packages).  The requirement
that this be done in such a way that the list of files within the stage1
package is no different than the list of files within a final package is an
additional, artificial constraint.  I don't believe it fundamentally makes
the bootstrapping problem any easier than if this were done ad-hoc.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: (was: Re: Bug#886238: Please introduce official nosystemd build profile)

[Steve Langasek]

On Tue, Jan 09, 2018 at 03:07:01PM +0100, Johannes Schauer wrote:
> Such a header could be introduced but that would be undesirable for two
> reasons:

>  - it would make it hard to check whether the binary packages a source package
>produces are really not different with a certain build profile active. 
> Right
>now, because of the lack of such a header, we can use the tools from the
>reproducible builds project to verify that a build profile does not tamper
>with package contents

>  - right now, a package is uniquely defined by dependency solvers through 
> their
>the name/version/architecture tuple. It would be possible to make this a
>quadruplet and let packages be unique by their
>name/version/architecture/profile property but that would require massive
>changes in even more parts of our infrastructure than the introduction of
>build profiles already required.

I think this is an unfortunate case of designing the solution to fit the
particular set of tools.

Build profiles, as a general thing (which they are supposed to be - this is
a major reason support took as long to land in dpkg as it did!), are
significantly less usable if the build profile doesn't follow the resulting
.deb as a tag.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: (was: Re: Bug#886238: Please introduce official nosystemd build profile)

[Johannes Schauer]

Quoting Paul Wise (2018-01-10 02:40:07)
> On Tue, Jan 9, 2018 at 10:07 PM, Johannes Schauer wrote:
> > No, there is no header in the binary packages that indicates with which
> > profile a source package was built to generate the given binary package.
> Is this information present in the new buildinfo files?

Yes. When --build-profiles option of dpkg-buildpackage sets the
DEB_BUILD_PROFILES environment variable. The value of that variable is captured
in the Environment field of the generated buildinfo file.

Thanks!

cheers, josch


signature.asc
Description: signature

Re: (was: Re: Bug#886238: Please introduce official nosystemd build profile)

[Paul Wise]

On Tue, Jan 9, 2018 at 10:07 PM, Johannes Schauer wrote:

> No, there is no header in the binary packages that indicates with which 
> profile
> a source package was built to generate the given binary package.

Is this information present in the new buildinfo files?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#886238: Build-Profiles purpose, mechanism vs policy (was Re: Bug#886238: Please introduce official nosystemd build profile)

[Sam Hartman]

> "Adrian" == Adrian Bunk  writes:

Adrian> On Tue, Jan 09, 2018 at 01:23:32PM +0100, Guillem Jover wrote:
>> ...  Given the background of build-profiles, I'm very much in
>> favor of introducing the equivalent usage as Gentoo USE flags,
>> which was its main intention! :) It could make Debian a viable
>> source-based distribution to use or base on, could make many of
>> the embedded specific distribution solutions obsolete, ...

Adrian> Who would then implement, maintain and support this in all
Adrian> packages?

No one.  People would implement and test the feature where it was
sufficiently useful to implement and test.  I don't think all of the use
flags combinations are tested in source distributions that have them
today.

Even so, users find those flags useful enough to spend a fair bit of
work on them.

A build profile seems like a great way to express the flag, and like
many things in Debian, the work would fall on those who would benefit
from it.

So, I do support the use of build profiles for use flags.
I also believe there's sufficient utility for downstreams and users to
justify this.

--Sam

Derivative specific build profiles (was: Re: Bug#886238: Please introduce official nosystemd build profile)

[Johannes Schauer]

Quoting Jeremy Bicha (2018-01-09 17:35:30)
> On Tue, Jan 9, 2018 at 9:07 AM, Johannes Schauer  wrote:
> > So we
> > could talk about whether we should allow more build profiles that change 
> > binary
> > package contents but so far I don't see the use case for them and thus the
> > discussion would be a bit academic.
> 
> Ok, let me try to provide a more practical use case for you then.
> 
> At times, Ubuntu needs to avoid certain build-dependencies because
> they would add an unwanted "universe" binary dependency to a "main"
> package. In some cases, that is the *only* change Ubuntu makes to the
> package. I believe it benefits Debian for Ubuntu and Debian packaging
> to be as shared as much as possible.
> 
> https://launchpad.net/bugs/1734339

That bug references [1] which lists reason for why derivative specific build
profiles are a bad idea. Even though I wrote most of the page it is of course
not up to me whether Debian at large thinks that derivative specific build
profiles are a good or bad idea. But if you want to discuss this topic, then
here are the downsides I see:

 - They are not self-explanatory. Building with nofoo active makes it clear
   that the source package is built without foo. What does it mean to build
   with the profile for ubuntu active, the profile for mint deactivated but at
   the same time the profile for kali active? Remember that more than one build
   profile can be enabled at a time. The same bug even admits that the src:git
   example could be solved with a nopcre2 build profile instead of a
   distribution specific profile.

 - What is more maintainable? This:

  ifeq (,$(filter ubuntu kali raspian steamos elementaryos, 
$(DEB_BUILD_PROFILES)))

   or this:

  ifeq (,$(filter nofoo, $(DEB_BUILD_PROFILES)))

   Who maintains the list of downstreams that we support? Who cleans up the
   archive once one of our downstreams is not maintained anymore? Who decides
   which downstreams are eligible to be included in every package that wants
   them? How do we prevent bitrot if we list all derivatives specifically?

 - Learning from others: Gentoo has a similar concept with USE flags and they
   also have downstreams but they do did not introduce derivative specific USE
   flags.

I thus believe that the superior solution is to name build profiles after the
feature that they modify. Then each downstream can pick and choose which set of
build profiles they activate when they build packages.

Thanks!

cheers, josch

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


signature.asc
Description: signature

Re: (was: Re: Bug#886238: Please introduce official nosystemd build profile)

[Johannes Schauer]

Quoting Adrian Bunk (2018-01-09 20:54:31)
> On Tue, Jan 09, 2018 at 01:22:33PM -0500, Michael Stone wrote:
> > On Tue, Jan 09, 2018 at 11:35:30AM -0500, Jeremy Bicha wrote:
> > > At times, Ubuntu needs to avoid certain build-dependencies because
> > > they would add an unwanted "universe" binary dependency to a "main"
> > > package. In some cases, that is the *only* change Ubuntu makes to the
> > > package. I believe it benefits Debian for Ubuntu and Debian packaging
> > > to be as shared as much as possible.
> > > 
> > > https://launchpad.net/bugs/1734339
> > $64k question: does having to maintain some notion of which build profiles
> > to use for a package (and actually maintaining the build profile upstream)
> > end up being less effort than a couple of lines of patch to remove a
> > dependency?
> We already have plenty of packages that use dpkg-vendor to check for ubuntu
> or raspbian in debian/rules, and adding something similar for build
> dependencies would sound reasonable to me.

Currently, the value of the Build-Depends field is just copied to the final
source package without making modifications. This is in contrast to the Depends
fields of the binary packages in debian/control which can get mangled depending
on their architecture annotations or substvars. What you propose would require
mangling the Build-Depends field at build-time which is a bad idea for several
reasons. Check out the following bugs:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677474

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751437

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#886238: Build-Profiles purpose, mechanism vs policy (was Re: Bug#886238: Please introduce official nosystemd build profile)

[Adrian Bunk]

On Tue, Jan 09, 2018 at 01:23:32PM +0100, Guillem Jover wrote:
>...
> Given the background of build-profiles, I'm very much in favor of
> introducing the equivalent usage as Gentoo USE flags, which was its
> main intention! :) It could make Debian a viable source-based
> distribution to use or base on, could make many of the embedded specific
> distribution solutions obsolete,
>...

Who would then implement, maintain and support this in all packages?

Implementing that global flags like
  USE="-systemd -alsa -pulseaudio -wayland"
work across all 30k source packages would be a huge amount of work.

And then supporting that any combination of disabling/enabling various 
flags builds and works for all packages at the quality level people 
expect from a Debian stable - that's completely out of scope of what 
Debian could achieve with its already stretched developer resources.

> Thanks,
> Guillem

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: (was: Re: Bug#886238: Please introduce official nosystemd build profile)

[Adrian Bunk]

On Tue, Jan 09, 2018 at 01:22:33PM -0500, Michael Stone wrote:
> On Tue, Jan 09, 2018 at 11:35:30AM -0500, Jeremy Bicha wrote:
> > At times, Ubuntu needs to avoid certain build-dependencies because
> > they would add an unwanted "universe" binary dependency to a "main"
> > package. In some cases, that is the *only* change Ubuntu makes to the
> > package. I believe it benefits Debian for Ubuntu and Debian packaging
> > to be as shared as much as possible.
> > 
> > https://launchpad.net/bugs/1734339
> 
> $64k question: does having to maintain some notion of which build profiles
> to use for a package (and actually maintaining the build profile upstream)
> end up being less effort than a couple of lines of patch to remove a
> dependency?

We already have plenty of packages that use dpkg-vendor to check for 
ubuntu or raspbian in debian/rules, and adding something similar for 
build dependencies would sound reasonable to me.

> Mike Stone

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: (was: Re: Bug#886238: Please introduce official nosystemd build profile)

[Michael Stone]

On Tue, Jan 09, 2018 at 11:35:30AM -0500, Jeremy Bicha wrote:

At times, Ubuntu needs to avoid certain build-dependencies because
they would add an unwanted "universe" binary dependency to a "main"
package. In some cases, that is the *only* change Ubuntu makes to the
package. I believe it benefits Debian for Ubuntu and Debian packaging
to be as shared as much as possible.

https://launchpad.net/bugs/1734339


$64k question: does having to maintain some notion of which build 
profiles to use for a package (and actually maintaining the build 
profile upstream) end up being less effort than a couple of lines of 
patch to remove a dependency?


Mike Stone

Re: (was: Re: Bug#886238: Please introduce official nosystemd build profile)

[Jeremy Bicha]

On Tue, Jan 9, 2018 at 9:07 AM, Johannes Schauer  wrote:
> So we
> could talk about whether we should allow more build profiles that change 
> binary
> package contents but so far I don't see the use case for them and thus the
> discussion would be a bit academic.

Ok, let me try to provide a more practical use case for you then.

At times, Ubuntu needs to avoid certain build-dependencies because
they would add an unwanted "universe" binary dependency to a "main"
package. In some cases, that is the *only* change Ubuntu makes to the
package. I believe it benefits Debian for Ubuntu and Debian packaging
to be as shared as much as possible.

https://launchpad.net/bugs/1734339

Thanks,
Jeremy Bicha

Re: (was: Re: Bug#886238: Please introduce official nosystemd build profile)

[Wookey]

On 2018-01-09 15:07 +0100, Johannes Schauer wrote:
> Quoting Wookey (2018-01-09 06:03:26)
> > On 2018-01-08 20:36 -0500, Michael Stone wrote:
> > > How, then, would you tell by looking at the package name+version which 
> > > kind
> > > of package you have? 
> > The package header says what profiles it was built with. The package
> > name+version doesn't change - that's part of the point. 
> 
> No, there is no header in the binary packages that indicates with which 
> profile
> a source package was built to generate the given binary package.

Oh. OK. My bad - apologies for putting bad info in this already-long
thread.  This was definitiely something we considered along the way
and I had thought it got implemented. Ah and in fact it did, but has
since been removed for reproducible-build compatibility, so I'm out
of date, not wrong :-)

An aside, but I'm not convinced this was the right thing to do. A
reproducible build doesn't mean 'reproductible even if you do
different things, like use a different build profile'. Having the
header had utility.

> Thus, we keep packages built with a different build profile but the same
> name/version/arcitecture bit-by-bit identical to each other.

OK, so the mechanism has morphed quite a lot from Guillem's (and then
my) original ideas, in the light of actually using it, to essentially
only be used at package granularity. And that makes sense because it
preserves the 'name/version/arch' tuple as a dependency identifier.

However we do have 'nodoc', which can't possibly produce bit-by-bit
identical packages (unless the docs are in a separate package) so I
don't see how it can be right to say "packages built with a different
build profile but the same name/version/arcitecture are bit-by-bit
identical to each other". Are you saying that you can't use nodoc if
there are docs in a package, or at least that you can only use it as a
build option, not a build profile?

Again, this is very much policy, not mechanism, and seems to me to be
more restrictive than is necessary.

> Technically speaking you are correct. We can add any arbitrary functionality 
> or
> build dependencies or package sets that are activated or deactivated through a
> certain set of build profiles. It is up to the derivatives which policy they
> use for the technical possibilities that build profiles offer.
> 
> So here on this list we can discuss the policies that we want to use for build
> profiles in Debian. As others already explained, a nosystemd profile does not
> make much sense, even if it were fine to change binary package contents. So we
> could talk about whether we should allow more build profiles that change 
> binary
> package contents but so far I don't see the use case for them and thus the
> discussion would be a bit academic.

I was talking about the general case of the possibilities of use for
build profiles. I have no strong opinion on how well that works in the
particular nosystemd case as I've not followed all that
discussion.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

(was: Re: Bug#886238: Please introduce official nosystemd build profile)

[Johannes Schauer]

Quoting Wookey (2018-01-09 06:03:26)
> On 2018-01-08 20:36 -0500, Michael Stone wrote:
> > How, then, would you tell by looking at the package name+version which kind
> > of package you have? 
> The package header says what profiles it was built with. The package
> name+version doesn't change - that's part of the point. No-one should be
> trying to put more than one instance of a package built with different
> profiles in one repo at one time because stuff will break. But a downstream
> distro could enable a profile and build everything that way and that should
> be fine.

No, there is no header in the binary packages that indicates with which profile
a source package was built to generate the given binary package.

Such a header could be introduced but that would be undesirable for two
reasons:

 - it would make it hard to check whether the binary packages a source package
   produces are really not different with a certain build profile active. Right
   now, because of the lack of such a header, we can use the tools from the
   reproducible builds project to verify that a build profile does not tamper
   with package contents

 - right now, a package is uniquely defined by dependency solvers through their
   the name/version/architecture tuple. It would be possible to make this a
   quadruplet and let packages be unique by their
   name/version/architecture/profile property but that would require massive
   changes in even more parts of our infrastructure than the introduction of
   build profiles already required.

Thus, we keep packages built with a different build profile but the same
name/version/arcitecture bit-by-bit identical to each other.

> > If you're going to change the name or version string anyway, why use some
> > complicated profile system instead of just applying a patch?
> 
> It's not really complicated. It's just a mechanism for variant package
> builds which is formalised in dpkg and related tools (without changing
> the package name/version).
> 
> And the reason why you'd use it for something like this is that it
> lets you upstream patches (which change dependencies) in a reasonably
> clean way.
> 
> Clearly a downstream distro can instead maintain patches, but we encourage
> upstreaming in general and this mechanism allows that.

One has to differentiate between the implementation of build profiles and the
policy of how we want to use them in Debian.

Technically speaking you are correct. We can add any arbitrary functionality or
build dependencies or package sets that are activated or deactivated through a
certain set of build profiles. It is up to the derivatives which policy they
use for the technical possibilities that build profiles offer.

So here on this list we can discuss the policies that we want to use for build
profiles in Debian. As others already explained, a nosystemd profile does not
make much sense, even if it were fine to change binary package contents. So we
could talk about whether we should allow more build profiles that change binary
package contents but so far I don't see the use case for them and thus the
discussion would be a bit academic.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#886238: Build-Profiles purpose, mechanism vs policy (was Re: Bug#886238: Please introduce official nosystemd build profile)

[Guillem Jover]

Hi!

[ Thanks, I also wanted to chime in and mention this, because it seems
  other people might not be clear on the history and motivations for
  build-profiles! ]

On Mon, 2018-01-08 at 18:37:11 +, Wookey wrote:
> On 2018-01-03 13:30 +, Simon McVittie wrote:
> > On Wed, 03 Jan 2018 at 15:12:51 +0300, Hleb Valoshka wrote:
> > > Please introduce official nosystemd build profile so downstream
> > > distributions can send patches to package maintainers with
> > > systemd-less build instead of keep them in home.
> > 
> > In general, build profiles are not meant
> > to result in functional changes to packages
> > (),
> 
> This is correct for the mechanism's main/original purpose of
> bootstrapping/removing cyclic dependencies.  The idea is that you
> can't change functionality and still use a dependency with the same
> name, if you actually want to automate the bootstrap process (because
> you don't know which features of a package the depending-on package
> uses).

Exactly, pretty much because otherwise doing automatic bootstrapping
(reusing existing package names and dependency relationships) becomes
either very hard or impossible to handle or reason about.

But, indeed, when I first envisioned build-profiles [B] it was due to
the embedded case, as a way to trim down packages and dependencies,
and trying come up with something that could make things like
debian/control.in (or worse :) unnecessary. Of course I also had
bootstrapping in mind, but it was secondary at the time. Which is
funny because, the reason this got finally implemented and deployed
in Debian was due to the boostrapping side, when an alternative and
less general proposal was put forward.

  [B] 

So, yes, the distinction between the tooling implenting just mechanism,
and letting the distribution specify policy was very much on purpose.
And while we were drafting the current spec, we also had in mind making
it powerful enough to be able to handle Gentoo USE flags cases, or
provide the features necessary to make things like openembedded and
co, unnecessary.

> > The speculation about a possible nosystemd profile in
> >  is
> > not consistent with that design principle. 
> 
> Right. But I'm not sure that the principles developed around
> bootstrapping necessarily have to apply to profiles developed for
> other purposes, and especially not for downstream distros who can
> define their own policy (within reason).
> 
> The other similar example is 'embedded'. You could have an 'embedded'
> profile that did more rigorous minimisation of packages for space or
> functionality, and exactly what that meant in local policy terms would
> be defined by the derivative using it.

Yes, build-profiles can be used any way we want to. Of course reusing
package-names while breaking the package-visible interface can be
dangerous or might outright break the dependency system. So that's
why we have tried to make that very clear on the spec.

There's also a distinction (which might not always be very clear)
between user-visible and package-visible interfaces. Say if something
is exclusively a user-visible interface, then disabling it via
build-profiles could be fine.

But in any case, nothing says we cannot introduce a namespace for such
interface breaking build-profiles, say: mutable.nosystemd, mutable.nopam,
mutable.nokrb5, mutable.nonls, mutable.noselinux, etc.

> > If the nosystemd profile is (exceptionally) allowed to cause functional
> > changes, what would the policy be for this build profile? Would it be
> > acceptable for a package built with nosystemd to be unusable or have
> > incompatible behaviour if it is used on a system booted with systemd?
> 
> I think that is up to the derivative to define.

Yes and no. When we specified that specific build-profiles are
distribution policies, that means that whoever defines those
build-profiles specifies their semantics. In case downstream want to
integrate those upstream (that is, Debian for example), then we'd
need to collectively agree on the semantics. But if a downstream or
independent project defines their own profiles, because they use their
own packaging or diverge w/o problem, then they can do whatever they
want, obviously.

Given the background of build-profiles, I'm very much in favor of
introducing the equivalent usage as Gentoo USE flags, which was its
main intention! :) It could make Debian a viable source-based
distribution to use or base on, could make many of the embedded specific
distribution solutions obsolete, and might make some downstreams life
easier. Of course using one of these mutable profiles might imply some
kind of flag day for their users, because either everything you want to
use is annotated or the dependency system might be broken, but given that
Debian does not enable an

sysvinit-utils essentialness (was: Re: Bug#886238: Please introduce official nosystemd build profile)

[Andreas Henriksson]

Hello all,

Given I've poked a bit at what Simon mentions below in the past and
don't really have any intention to follow this (and any other remaining
item mentioned at [0]) through (and not aware of anyone else picking it
up either), I thought I'd take this opportunity to share a bit about my
view on it in the hope that it can help someone pick it up.

On Sun, Jan 07, 2018 at 11:54:49AM +, Simon McVittie wrote:
[...]
> sysvinit-utils is still Essential: yes, because it contains binaries that
> were historically part of the Essential set; *that* keeps src:sysvinit
> in testing. There are plans to make sysvinit-utils non-Essential by
> moving pidof to a new Essential package built from src:procps (lots
> of packages blindly assume that pidof exists, so adding dependencies
> doesn't seem feasible) and adding dependencies for the few uses of the
> other sysvinit-utils binaries, which have been OK'd in principle by the
> maintainer of src:sysvinit, but haven't happened yet.
[...]

First, what Simon says is in my view an accurate description.

Using the pidof implementation provided by procps (upstream) would
mean we atleast use the same implementation as other distros, but
wouldn't gain us much else and could even give us new problems.
By building an essential procps-pidof package would relieve src:sysvinit
from bootstrapping, but instead introduce src:procps. I assume
bootstrappers have sysvinit well under control already, but no idea if
procps would cause issues for them (possibly it may need to introduce
some build profiles atleast).

In the best of worlds we would make pidof non-essential. So who are
the users? Well unfortunately it's not very easy to codesearch[1]
for pidof users, because there are lots of "false positives" (and
I'm not as patient and thorough as Helmut has been while investigating
e2fsprogs), but from glancing over the results the main users of pidof
seems to be init scripts. One potential solution here could be to
replace the pidof usage with the LSB function pidofproc[2] (but note how
the optional last "unspecified method" in practise seems to be
implemented by calling pidof[3] when available and I'm not what the
impact would be if the first condition that today always is true starts
becoming false most of the time instead). While looking at a selection
of these init scripts they stand out as very old style. Likely updating
them to be somewhat modern (by sysvinit standards) would likely mean
totally rewriting them as LSB compatible init scripts.
I personally doubt we'll see a major widespread effort within the Debian
community to overhaul init scripts in our archive at this point. (Even
the Debian LSB maintainer says LSB is basically dead at this point, but
as a challenge to all potential sysvinit supporters out there please
prove me wrong by makin Debians init scritps LSB compatible!)

If anyone out there has ideas on how we could practically (iow, with a
somewhat sane amount of work) accomplish this in a different way I'd be
interested in hearing about it.

The most practical thing to do at this point seems to be to just wait
until sysvinit is eventually removed from Debian, add a lintian check
that suggests people to also drop any init scripts they're shipping
in their packages (cf. the upstart removal which happened surprisingly
quickly in my view but may not be comparable), and then investigate
after a while again where we have pidof users and if the package
providing pidof can be demoted to non-Essential. Given that we're still
having these threads like the one leading up to this message makes me
think this in not happening any time soon though

If anyone out there is interested in working on this (or any other item
on [0], or anything similar/related to it) please contact me!

HTH

Regards,
Andreas Henriksson

PS. Don't assume I'm subscribed to this (or any other) list!

[0]: https://wiki.debian.org/BusterPriorityRequalification
[1]: https://codesearch.debian.net/search?q=pidof&perpkg=1
[2]: http://refspecs.linuxbase.org/LSB_3.0.0/LSB-PDA/LSB-PDA/iniscrptfunc.html
[3]: https://sources.debian.org/src/lsb/9.20170808/init-functions/#L108