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

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

Bug#886238: Please introduce official nosystemd build profile

[Steve Langasek]

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.

As a policy, I think it's clear that packages built with non-default
profiles should never be included in the Debian archive; and segregating
packages into archives by stage is a sensible way to do this for
bootstrapping.  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...

In any case, I think the value actually accrues primarily to the simple
cases; because if you want to maintain a package over time, setting a flag
and rebuilding requires much less human involvement than having to
repeatedly merge changes into a package.

-- 
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

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

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

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

Bug#886238: Please introduce official nosystemd build profile

[Ian Campbell]

On Tue, 2018-01-09 at 05:03 +, Wookey wrote:
> 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.

And is the reason this is preferable to `dpkg-vendor` based stuff
because `dpkg-vendor` cannot affect debian/control in the same way
(without tricks to autogenerate control at build time)?

> Clearly a downstream distro can instead maintain patches, but we
> encourage upstreaming in general and this mechanism allows that. 

This requires that Debian defines (together with the downstream(s)) a
semantic for the profile which satisfies them. Previously in the thread
you said "I think that is up to the derivative to define" which I think
isn't the case, it has to be a Debian based policy if the patches are
to go into Debian. What happens if two downstreams have different ideas
of what a given profile should mean?

Going down this path starts to look a lot like the USE flags used by
source base distros, and while it might be tollerable as a one off it
seems likely that once the precedent is established the usage will
proliferate (noselinux, noapparmor, nodbus, noblah,...) which would
seem to go against our current principal of enabling most options if
they cause no harm if not used.

I also agree with Russ' point that on the case of `nosystemd` we
actually want to be able to support that use case in Debian, and a
profile for use by downstreams doesn't appear to satisfy that need.

Ian.

Bug#886238: Please introduce official nosystemd build profile

[Wookey]

On 2018-01-08 20:36 -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? 

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. 

> 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. 

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


signature.asc
Description: PGP signature

Bug#886238: Please introduce official nosystemd build profile

[Michael Stone]

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.


Mike Stone

Bug#886238: Please introduce official nosystemd build profile

[Steve Langasek]

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.


On Mon, Jan 08, 2018 at 06:37:11PM +, 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).

> > 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.

> > 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.
> 
> I agree that this matter needs a bit of thought. The profile spec has
> evolved quite a lot since the mechanism was initially created. The
> focus has very much been on supporting bootstrapping, which provides a
> particular set of constraints. 
> 
> It's not necessarily wrong to use the mechanism in different ways, but
> it does require some thought about the assumptions made by tools to
> see if this actually makes sense. Some changes could be too intrusive
> to make using build-profiles, and should simply be kept as a
> dopwnstream patch, but in practice I expect that a well-defined use
> like this would actually work quite well, producing quite clean,
> maintainable patches. Ultimately it would be up to maintainers wether
> they found it too intrusive or not, and if they did to ask the
> derivative to just keep the patch to themselves.
>  
> I have not read most of this thread, so this may already have been
> said, sorry if I am repeating something. Like Simon and Johannes I am
> keen to stick to the technical issue.
> 
> I agree with Simon that defining an architecture to try and deal with
> this is abuse of that mechanism. An architecture is an ABI and life is
> complicated enough without adding baggage to that concept.
> 
> Wookey
> -- 
> Principal hats:  Linaro, Debian, Wookware, ARM
> http://wookware.org/



-- 
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

Bug#886238: closed by Bastian Blank (Re: Bug#886238: Please introduce official nosystemd build profile)

[Philip Hands]

On Mon, 08 Jan 2018, Hleb Valoshka <375...@gmail.com> wrote:
> On 1/8/18, Don Armstrong  wrote:
>
>> Devuan does not support reading the new upstream configuration file,
>> which is what new patches are needed to support. This is pretty classic
>> bitrot of an underused/under-tested execution path.
>
> It does: 
> https://git.devuan.org/devuan-packages/dnscrypt-proxy/blob/suites/ascii-proposed/debian/dnscrypt-proxy.init

Well done.

I note that your init script is not the same as the one in the bug's
patch, and is also not the same as the one that reverting the commit you
were on about would have resurrected.

I would hope that between the three versions there is one (or a
combination) that would function both on a system where the systemd
support files are present (as in the Debian package) and where they are
absent (as is the case in yours). If not, presumably that would not take
a vast effort to achieve.

That being the case, I'd suggest that you mail the bug with your script
attached, pointing out the interesting differences between it and the
existing patch, and perhaps offering to help testing the result.

I sincerely hope that doing that would result a rather happier outcome
than your efforts to date seem to have achieved.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#886238: Please introduce official nosystemd build profile

[Wookey]

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).

> 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.

> 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.

I agree that this matter needs a bit of thought. The profile spec has
evolved quite a lot since the mechanism was initially created. The
focus has very much been on supporting bootstrapping, which provides a
particular set of constraints. 

It's not necessarily wrong to use the mechanism in different ways, but
it does require some thought about the assumptions made by tools to
see if this actually makes sense. Some changes could be too intrusive
to make using build-profiles, and should simply be kept as a
dopwnstream patch, but in practice I expect that a well-defined use
like this would actually work quite well, producing quite clean,
maintainable patches. Ultimately it would be up to maintainers wether
they found it too intrusive or not, and if they did to ask the
derivative to just keep the patch to themselves.
 
I have not read most of this thread, so this may already have been
said, sorry if I am repeating something. Like Simon and Johannes I am
keen to stick to the technical issue.

I agree with Simon that defining an architecture to try and deal with
this is abuse of that mechanism. An architecture is an ABI and life is
complicated enough without adding baggage to that concept.

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


signature.asc
Description: PGP signature

Bug#886238: closed by Bastian Blank (Re: Bug#886238: Please introduce official nosystemd build profile)

[Hleb Valoshka]

On 1/8/18, Don Armstrong  wrote:

> Devuan does not support reading the new upstream configuration file,
> which is what new patches are needed to support. This is pretty classic
> bitrot of an underused/under-tested execution path.

It does: 
https://git.devuan.org/devuan-packages/dnscrypt-proxy/blob/suites/ascii-proposed/debian/dnscrypt-proxy.init

Bug#886238: closed by Bastian Blank (Re: Bug#886238: Please introduce official nosystemd build profile)

[Ian Campbell]

On Mon, 2018-01-08 at 08:46 -0800, Don Armstrong wrote:
> All of that said, if you are interested in Debian supporting a nosystemd
> build profile, continuing to escalate conflicts with other developers is
> not helping your cause.

It would be more helpful if people on _both_ sides would stop
needlessly antagonising each other. There has been plenty of mud (and
escalation) going in both directions in this thread -- I don't care who
started it, everyone involved here really ought to know better than to
respond in kind and make things worse.

Ian.

Bug#886238: closed by Bastian Blank (Re: Bug#886238: Please introduce official nosystemd build profile)

[Don Armstrong]

On Mon, 08 Jan 2018, Hleb Valoshka wrote:
> "as it was in previous package versions"
>
> It was removed in 1.8.1-3, but it was in <= 1.8.1-2.

It was removed in 1.8.1-3 because upstream has switched to distributing
a dns-dnscrypt-proxy.conf and /etc/default/dnsscript-proxy is no longer
used at all.

> There is no need for new patches, he just needs to do `git revert
> de160d3eeb320`. That's all. I wrote this in the previous mail but w/o
> sha-id. Devuan package ships that old init scripts with small changes.

Devuan does not support reading the new upstream configuration file,
which is what new patches are needed to support. This is pretty classic
bitrot of an underused/under-tested execution path.

All of that said, if you are interested in Debian supporting a nosystemd
build profile, continuing to escalate conflicts with other developers is
not helping your cause.

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

I've had so much good luck recently I was getting sated with it. It's
like sugar, good luck. At first it's very sweet, but after a while you
start to think: any more of this and I shall be sick.
 -- Adam Roberts _Yellow Blue Tibia_ p301

Bug#886238: closed by Bastian Blank (Re: Bug#886238: Please introduce official nosystemd build profile)

[Hleb Valoshka]

On 1/8/18, Philip Hands  wrote:
>> I've already posted a bug number which perfectly shows how bugs for
>> systemd-less systems are treated.
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850069
>>
>>> Control: severity -1 wishlist
>>
>> W_I_S_H_L_I_S_T_!
>>
>> System is broken,
>
> Wrong.

You wrong.

"as it was in previous package versions"

Should I explain what that means? It was removed in 1.8.1-3, but it
was in <= 1.8.1-2.

> Without the merged bug, there is no patch, so in that case you would
> have nothing to complain about (maintainers are _NOT_ required to fix
> such bugs, but should not reject patches without good reason).

There is no need for new patches, he just needs to do `git revert
de160d3eeb320`. That's all.
I wrote this in the previous mail but w/o sha-id. Devuan package ships
that old init scripts with small changes.

Please read what was written.

Bug#886238: closed by Bastian Blank (Re: Bug#886238: Please introduce official nosystemd build profile)

[Philip Hands]

On Sun, 07 Jan 2018, Hleb Valoshka <375...@gmail.com> wrote:
> On 1/5/18, Debian Bug Tracking System  wrote:
>> From: Bastian Blank 
> ...
>> As you have been already told by several people, Debian supports
>> systemd-less systems.  If you find bugs running in this mode, please
>> file bug reports.
>
> I've already posted a bug number which perfectly shows how bugs for
> systemd-less systems are treated.
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850069
>
>> Control: severity -1 wishlist
>
> W_I_S_H_L_I_S_T_!
>
> System is broken,

Wrong.

Which bit of this reply is not clear to you?

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857322#10

Did you perhaps miss the fact that the two bugs had been merged?

Without the merged bug, there is no patch, so in that case you would
have nothing to complain about (maintainers are _NOT_ required to fix
such bugs, but should not reject patches without good reason).

With the merged bug, we have a patch that is described as "prelimiary"
and suggests a way of testing it. :

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857322#25

Therefore it needs testing before one could legitimately complain about
the maintainer blocking it.

Have you contributed to that testing?

If so, why is that not visible in the bug?

If not, how about putting your efforts into something useful (testing),
rather than wasting your and our time with this intemperate drivel?

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#886238: closed by Bastian Blank (Re: Bug#886238: Please introduce official nosystemd build profile)

[Hleb Valoshka]

On 1/5/18, Debian Bug Tracking System  wrote:
> From: Bastian Blank 
...
> As you have been already told by several people, Debian supports
> systemd-less systems.  If you find bugs running in this mode, please
> file bug reports.

I've already posted a bug number which perfectly shows how bugs for
systemd-less systems are treated.

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

> Control: severity -1 wishlist

W_I_S_H_L_I_S_T_!

System is broken, it's not able to resolve hostnames, but for fanboys
it's not a grave issue, it's just a "wishlist". While to return SysV
support only oneliner is required:

git revert $badcommint && gbp dch && dch -r && gbp buldpackage && dput ...

For me it was much easier to upload the fixed version to Devuan than
convince the maintainer that this oneliner is not a "burden" as he
says.

> Apart from that, I don't see that you managed to describe what a
> "nosystemd" profile would actually do.  This would be the least we would
> need from such a bug report.

If you really needed such information you would ask for it, add
appropriate tags, etc. But you just closed it so It just means that
you are absolutely not interested in this.

But the idea was the following:
1) Debian recognizes 'nosystemd' as official build profile, so it
actually means "adds it to lintian".
2) Devuan community creates patches that allows usage of the profile,
so packages built with it have only sane dependencies.
3) If DD/DM is a fanboy, s/he doesn't accepts the patches and we keep
them in our repository.
4) In Debian packages are build without the profile enabled.
5) In Devuan they are automatically rebuilt with it. No manual
interaction is required.
6) Profit. Everybody are happy.

Of course, some persons tries to convince that without running s*d
libsystemd0 does nothing, actually it does, at least sd_notify() (I
believe 99% daemons use only it) writes to unix socket listed in
$NOTIFY_SOCKET without any checks what actually listens on another
side. Do we really need an additional library to send random crap to
random socket? I doubt.

> However what I see is, that you and others instead of actually engaging
> in discussions just referred to personal attacks.  I and others consider
> this unacceptable behaviour on our technical mailing lists and our bug
> tracker.  Please be adviced that I will ask both the BTS owner and the
> list masters to block you from ever posting again if this behaviour
> continues.

Have you sent the same warnings to your mates from LP fanclub who
actually started attacking those willing to keep away from s*d
accusing them being "disturbed persons" even "zealots", i.e. fanatical
killers and terrorists killing everybody who doesn't support them?

> As I don't think anything new will come up, I'm closing this bug report.
> Don't reopen it, this might just expedite your fate.

Typical reaction for a fanboy. "Only my opinion is a correct one. All
other are incorrect and their owners should be banned."

Of course you can ban. Debian took the wrong direction from being
community driven distribution to being a testbed and advocate for
corporations, but I don't want to work for free  for canonical/rh/etc.
I spent some time during the last five years maintaining two dozens of
packages in Debian, but if Debian doesn't tolerate dissent any more
treat this as request for removal for them.

Bug#886238: Please introduce official nosystemd build profile

[Chris Lamb]

Matthias,

> > > > (accusing Debian to "vandalize" open source by supporting systemd)
[..]
> > > I was accused of this on the "dng" mailing list. It should be easy to
> > > find the relevant threads.
[..]
> > And you were accused because you had removed (broken) functionality
> > from sysv script and had reimplemented it but for systemd only.
> 
> Well, removing broken functionality is a fair deal. And implementing a
> systemd-only version is as well

Thank you for your spirited defense but it is not needed as I didn't
re-implement it for systemd only. I tire of correcting the dng folks
on this quite elementary and obvious point.


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#886238: Please introduce official nosystemd build profile

[Matthias Klumpp]

2018-01-07 20:00 GMT+01:00 Hleb Valoshka <375...@gmail.com>:
> On 1/6/18, Chris Lamb  wrote:
>>> > (accusing Debian to "vandalize" open source by supporting systemd)
>> […]
>>> 1) Proofs please. DDG & Google find only your words.
>>
>> I was accused of this on the "dng" mailing list. It should be easy to
>> find the relevant threads.
>
> To be honest there were quite opposite statements as well, weren't
> they? From another Devuan's core team member.
>
> And you were accused because you had removed (broken) functionality
> from sysv script and had reimplemented it but for systemd only.

Well, removing broken functionality is a fair deal. And implementing a
systemd-only version is as well - afterall, it is his decision on how
he spends his time and which usecases he supports. It helps nobody to
have someone write code for a feature they don't actually use (the
result will be bad in any case, due to limited testing).
This situation would have an easy fix though: People who do care about
SysVInit could provide a patch to fix the broken functionality.
Debian lives from collaboration, and if enough people care about a
feature (like SysVInit support) and work on it, that particular
feature will be supported. If on the other hand, no work is done to
keep the feature alive, its codepaths will first deteriorate and after
a while it will be removed entirely.

So, tl;dr and what a lot of people have said before: SysVInit needs
developers interested or paid to work on it to stay alive in Debian.
It also requires users to find and report bugs related to it. A new
build profile will not magically create developers to address SysVInit
issues.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#886238: Please introduce official nosystemd build profile

[Hleb Valoshka]

On 1/6/18, Chris Lamb  wrote:
>> > (accusing Debian to "vandalize" open source by supporting systemd)
> […]
>> 1) Proofs please. DDG & Google find only your words.
>
> I was accused of this on the "dng" mailing list. It should be easy to
> find the relevant threads.

To be honest there were quite opposite statements as well, weren't
they? From another Devuan's core team member.

And you were accused because you had removed (broken) functionality
from sysv script and had reimplemented it but for systemd only.

Bug#886238: Please introduce official nosystemd build profile

[Chris Lamb]

Hleb,

> > (accusing Debian to "vandalize" open source by supporting systemd)
[…]
> 1) Proofs please. DDG & Google find only your words.

I was accused of this on the "dng" mailing list. It should be easy to
find the relevant threads.


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb, Debian Project Leader 2017
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#886238: Please introduce official nosystemd build profile

[Eduard Bloch]

Hallo,
* Johannes Schauer [Wed, Jan 03 2018, 08:24:49PM]:
> > The speculation about a possible nosystemd profile in
> >  is
> > not consistent with that design principle. If a package contains systemd
> > units or uses of libsystemd, then it's safe to assume they were added for a
> > reason. Whether you value that reason or not, it's nearly always true to say
> > that cutting out systemd-related bits is a functional change.
> 
> Cutting out systemd-related bits is probably a functional change in most 
> cases.

It depends. Properly written software which checks for libsystemd-*
stuff at compile time would, in theory, support such polymorphic style
of integration. The question is - how many packages are prepared for
this, and how many upstreams have already moved to "only Linux and only
systemd" style?

I, for one, do still support non-systemd mode in my software (i.e.
upstream hat on) explicitly - but it's not sufficiently tested anymore
and relies on feedback from users from non-Linux worlds. And it requires
additional work, so some upstream developers might be tempted to drop
non-non-systemd support whatsoever.

So my general feeling is that we might add this profile but it is not
something which should be pushed through, at the expense of Debian
maintainers. It would be manpower stolen from us for the benefit of
ideological warriors from the "weird party". Which is something I am not
comfortable with.

Regards,
Eduard.

Bug#886238: Please introduce official nosystemd build profile

[Lars Wirzenius]

On Thu, Jan 04, 2018 at 10:44:24PM +0300, Hleb Valoshka wrote:
> On 1/3/18, Steve Langasek  wrote:
> 
> > Moreover, defining an official nosystemd profile in Debian signals that we
> > are willing to support it, which means any maintainers who refuse such
> > patches will immediately become the targets of abuse from anti-systemd
> > zealots.
> 
> "anti-systemd zealots" Steve, when did you join LP fanclub? When
> Ubuntu decided to throw away your upstart and use systemd instead?
> Should I remind your votes in CTTE?
> 
> Please take your Ubuntu employee hat off and speak as DD.

I think you're out of line. Please stop.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#886238: Please introduce official nosystemd build profile

[Marco d'Itri]

On Jan 04, Hleb Valoshka <375...@gmail.com> wrote:

> "anti-systemd zealots" Steve, when did you join LP fanclub? When
> Ubuntu decided to throw away your upstart and use systemd instead?
Classy...

> Do we have runtime systemd detection in all software linked against
> libsystemd so it will work properly in absence of systemd? To rebuild
Yes, because it is built-in in libsystemd.
Please file bugs if you can find any counterexamples.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#886238: Please introduce official nosystemd build profile

[Hleb Valoshka]

On 1/3/18, Steve Langasek  wrote:

> Moreover, defining an official nosystemd profile in Debian signals that we
> are willing to support it, which means any maintainers who refuse such
> patches will immediately become the targets of abuse from anti-systemd
> zealots.

"anti-systemd zealots" Steve, when did you join LP fanclub? When
Ubuntu decided to throw away your upstart and use systemd instead?
Should I remind your votes in CTTE?

Please take your Ubuntu employee hat off and speak as DD.


> Building a derivative around the exclusion of libsystemd from the
> filesystem is not technically defensible.

Do we have runtime systemd detection in all software linked against
libsystemd so it will work properly in absence of systemd? To rebuild
software without libsystemd is the only reliable way to ensure that
non-systemd code pathes are in use.

> This is a purely political fork, and it's
> politics that we should stay entirely clear of.

Steve, you much, much better than anybody else know that the only
political decision made it's a systemd as a default pid 1. Should I
remind how many votes were held until the result satisfying
pro-systemd party was achieved?

Bug#886238: Please introduce official nosystemd build profile

[Johannes Schauer]

Quoting Hleb Valoshka (2018-01-04 19:35:28)
> On 1/3/18, Andrew Shadura  wrote:
> > Do we really need systemd-less builds? I'm not convinced this is something
> > relevant to Debian.
> [...]
> https://wiki.debian.org/BuildProfileSpec#Derivative_specific_profiles
> 
> At least some DD have a different POV.

The fact that I gave that example on that wiki page does *not* imply that I
would be in favour of build profiles being used for this purpose. I was merely
making an example of what could be technically possible. I gladly switch this
example for another.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#886238: Please introduce official nosystemd build profile

[Hleb Valoshka]

On 1/3/18, Ansgar Burchardt  wrote:

> I think there is only one distribution which wants builds without
> libsystemd: the one that formed around MikeeUSA's call to action.

1) Even Wikipedia knows 43 distributions, much more can be found on
http://without-systemd.org/wiki/index.php/Main_Page#GNU.2FLinux_distributions,
some of them are still Debian based (but migrate to Devuan).

2) Please provide proofs for relationship between MikeeUSA and Devuan project.

> What does Debian gain from supporting a distribution whose developers
> are unfriendly to Debian developers (accusing Debian to "vandalize"
> open source by supporting systemd) and other people (calling a systemd
> developer a cancer)?

1) Proofs please. DDG & Google find only your words.

2) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850069
After this I have switched to Devuan.

> Let me quote Devuan's IRC's infobot fact:

Of course this is lie and LP & his fans are very pleasant people.

Bug#886238: Please introduce official nosystemd build profile

[Hleb Valoshka]

On 1/3/18, Andrew Shadura  wrote:

> Do we really need systemd-less builds? I'm not convinced this is
> something relevant to Debian.

http://angband.pl/deb/archive.html

https://wiki.debian.org/BuildProfileSpec#Derivative_specific_profiles

At least some DD have a different POV.

Bug#886238: Please introduce official nosystemd build profile

[Wouter Verhelst]

Hi Steve,

On Wed, Jan 03, 2018 at 10:48:06AM -0800, Steve Langasek wrote:
> On Wed, Jan 03, 2018 at 09:13:24AM -0500, Paul R. Tagliamonte wrote:
> > Conversely, if the patches are invasive and unmaintainable, its not on
> > Debian to merge them.
> 
> Moreover, defining an official nosystemd profile in Debian signals that we
> are willing to support it, which means any maintainers who refuse such
> patches will immediately become the targets of abuse from anti-systemd
> zealots.
> 
> Building a derivative around the exclusion of libsystemd from the filesystem
> is not technically defensible.  This is a purely political fork, and it's
> politics that we should stay entirely clear of.

Hrm. I hadn't looked at it from that angle, but you're right. Thanks for
pointing that out.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#886238: Please introduce official nosystemd build profile

[Steve Langasek]

On Wed, Jan 03, 2018 at 02:48:11PM -0900, Britton Kerin wrote:
> On 1/3/18, Steve Langasek  wrote:
> > On Wed, Jan 03, 2018 at 09:13:24AM -0500, Paul R. Tagliamonte wrote:
> >> Conversely, if the patches are invasive and unmaintainable, its not on
> >> Debian to merge them.

> > Moreover, defining an official nosystemd profile in Debian signals that we
> > are willing to support it, which means any maintainers who refuse such
> > patches will immediately become the targets of abuse from anti-systemd
> > zealots.

> > Building a derivative around the exclusion of libsystemd from the
> > filesystem is not technically defensible.  This is a purely political
> > fork, and it's politics that we should stay entirely clear of.

> As a random long-time user, I recently bought a new pre-built laptop
> with debian and got the systemd fun for the first time.  Decided no
> more debian for me in the future.  I'm pleased to hear that there are
> derivative distros that resist systemd and encourage debian to *allow*
> them, assuming people are willing to do the work.  *Not* allowing this is
> the politics-driven position.

You have misunderstood the technical significance of the proposed
'nosystemd' profile, which is not in any way required in order to support
running a Debian system with an init other than systemd.

-- 
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

Bug#886238: Please introduce official nosystemd build profile

[Britton Kerin]

On 1/3/18, Steve Langasek  wrote:
> On Wed, Jan 03, 2018 at 09:13:24AM -0500, Paul R. Tagliamonte wrote:
>> Conversely, if the patches are invasive and unmaintainable, its not on
>> Debian to merge them.
>
> Moreover, defining an official nosystemd profile in Debian signals that we
> are willing to support it, which means any maintainers who refuse such
> patches will immediately become the targets of abuse from anti-systemd
> zealots.
>
> Building a derivative around the exclusion of libsystemd from the
> filesystem
> is not technically defensible.  This is a purely political fork, and it's
> politics that we should stay entirely clear of.

As a random long-time user, I recently bought a new pre-built laptop
with debian and got the systemd fun for the first time.  Decided no
more debian for me in the future.  I'm pleased to hear that there are
derivative distros that resist systemd and encourage debian to *allow*
them, assuming people are willing to do the work.  *Not* allowing this is
the politics-driven position.

Britton

Bug#886238: Please introduce official nosystemd build profile

[Johannes Schauer]

Quoting Simon McVittie (2018-01-03 14:30:55)
> 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
> (),
> which seems like it isn't a great fit for omission of systemd support:
> if a package installs systemd units, links to libsystemd, etc., it's
> usually because it causes a functional difference to that package's
> behaviour on systems that booted with systemd as pid 1, or on systems
> where `systemd --user` is available.

Main author of that wiki page here.

Disclaimer: These "policies" outlined on that page have been agreed upon by the
people involved in bootstrapping Debian. AFAIK there was never a project-wide
consensus about these rules.

The reason why most build profiles completely forbid changes to the produced
binary packages is, that otherwise this would undermine the contracts formed by
our dependency system. Ultimately, we want to automatically resolve dependency
cycles. But reasoning over dependencies in that way is only possible if a
binary package with the same name, version and architecture also always
contains the same content. Otherwise a package foo (build-)depending on another
package bar would not be able to rely on the functionality it expects bar to
provide. Ideally, binary packages would even stay the same bit-by-bit. Thus, a
package which for example wants to add the nopython build profile would need to
move all its Python-specific content into a separate binary package (if that's
not the case already) and then not build that binary package if the nopython
build profile is active.

> The speculation about a possible nosystemd profile in
>  is
> not consistent with that design principle. If a package contains systemd
> units or uses of libsystemd, then it's safe to assume they were added for a
> reason. Whether you value that reason or not, it's nearly always true to say
> that cutting out systemd-related bits is a functional change.

Cutting out systemd-related bits is probably a functional change in most cases.
The only way to introduce a nosystemd profile and adhere to the restriction of
not introducing functional changes into existing binary packages once that
profile is active, would be to add a new set of "nosystemd" binary packages. So
the speculation you quote above is consistent with the design principle but it
requires invasive changes to the packaging of all packages surrounding systemd.
So a debian/control would look like:

# this is the normal package
Package: foo
Build-Profiles: 
Depends: libsystemd, bar, [...]

# this is the package built when the nosystemd build profile is active
Package: foo-nosystemd
Build-Profiles: 
Depends: bar, [...]

Plus all required changes in debian/rules to support this. Pulling this off
while adhering to the existing rules would certainly go beyond the complexity
that other build profiles currently require.

> 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?
> 
> (Clearly, that would be a silly thing to do, because if you care about
> avoiding systemd enough to be specially rebuilding packages, then you
> certainly shouldn't boot with systemd as your process 1; but there's no
> technical restriction that prevents that from happening.)

If such an exception were added, then any tool used for bootstrapping would
have to carry a list of profiles that are not safe to use because packages
built with that profile do potentially break dependency assumptions. Right now,
the only set of build profile names that are allowed to produce binary packages
with functional changes is the pkg.$sourcepackage.$anything pattern which
allows source package maintainers to experiment. For that reason, I'd like to
avoid introducing more build profiles that are allowed to break dependency
contracts.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#886238: Please introduce official nosystemd build profile

[Steve Langasek]

On Wed, Jan 03, 2018 at 09:13:24AM -0500, Paul R. Tagliamonte wrote:
> Conversely, if the patches are invasive and unmaintainable, its not on
> Debian to merge them.

Moreover, defining an official nosystemd profile in Debian signals that we
are willing to support it, which means any maintainers who refuse such
patches will immediately become the targets of abuse from anti-systemd
zealots.

Building a derivative around the exclusion of libsystemd from the filesystem
is not technically defensible.  This is a purely political fork, and it's
politics that we should stay entirely clear of.


> On Jan 3, 2018 9:09 AM, "Wouter Verhelst"  wrote:
> 
> On Wed, Jan 03, 2018 at 01:59:05PM +0100, Andrew Shadura wrote:
> > Hi,
> >
> > On 3 January 2018 at 13:12, Hleb Valoshka <375...@gmail.com> wrote:
> > > Package: general
> > > Severity: wishlist
> > >
> > > 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.
> >
> > Do we really need systemd-less builds? I'm not convinced this is
> > something relevant to Debian.
> 
> We don't *need* them, but it's not a problem if people want to support
> it. Debian has always allowed things to be defined by those that want to
> do the work.
> 
> If adding an official "nosystemd" build profile makes life easier for
> people who want to support systemd-less builds, and they send patches to
> keep the build profile actually working, then that doesn't hurt us in
> any way and I think we should do it.
> 
> --
> Could you people please use IRC like normal people?!?
> 
>   -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
>  Hacklab

-- 
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

Bug#886238: Please introduce official nosystemd build profile

[Ansgar Burchardt]

On Wed, 2018-01-03 at 14:26 +0100, Samuel Thibault wrote:
> > Do we really need systemd-less builds? I'm not convinced this is
> > something relevant to Debian.
> 
> Well, if Debian wants to remain relevant to downstreams, it'd be
> better to accomodate their needs.

I think there is only one distribution which wants builds without
libsystemd: the one that formed around MikeeUSA's call to action.

What does Debian gain from supporting a distribution whose developers
are unfriendly to Debian developers (accusing Debian to "vandalize"
open source by supporting systemd) and other people (calling a systemd
developer a cancer)?

Let me quote Devuan's IRC's infobot fact:

| 'sth is poettering' means it acts invasive, possessive, destructive,
| and generally in an egocentric exacerbating negative way. ``this
| cancer is extremely poettering'', [...]

I don't think we should waste time to accomodate the needs of such
people.

Ansgar

Bug#886238: Please introduce official nosystemd build profile

[Wouter Verhelst]

On Wed, Jan 03, 2018 at 09:13:24AM -0500, Paul R. Tagliamonte wrote:
> Conversely, if the patches are invasive and unmaintainable, its not on Debian
> to merge them.

Yes. But adding a "nosystemd" build profile is in no way "invasive and
unmaintainable".

(why the top-post?)

> On Jan 3, 2018 9:09 AM, "Wouter Verhelst"  wrote:
> 
> On Wed, Jan 03, 2018 at 01:59:05PM +0100, Andrew Shadura wrote:
> > Hi,
> >
> > On 3 January 2018 at 13:12, Hleb Valoshka <375...@gmail.com> wrote:
> > > Package: general
> > > Severity: wishlist
> > >
> > > 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.
> >
> > Do we really need systemd-less builds? I'm not convinced this is
> > something relevant to Debian.
> 
> We don't *need* them, but it's not a problem if people want to support
> it. Debian has always allowed things to be defined by those that want to
> do the work.
> 
> If adding an official "nosystemd" build profile makes life easier for
> people who want to support systemd-less builds, and they send patches to
> keep the build profile actually working, then that doesn't hurt us in
> any way and I think we should do it.
> 
> --
> Could you people please use IRC like normal people?!?
> 
>   -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf
> 2008
>      Hacklab
> 
> 
> 

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#886238: Please introduce official nosystemd build profile

[Roberto C . Sánchez]

On Wed, Jan 03, 2018 at 02:25:03PM +0100, Marco d'Itri wrote:
> On Jan 03, Andrew Shadura  wrote:
> 
> > Do we really need systemd-less builds? I'm not convinced this is
> > something relevant to Debian.
> Not at all.
> This would be a lot of work for the benefit of a tiny audience: the 
> disturbed people who hate systemd so much that they cannot accept even 
> that libsystemd is installed on their computers.
> 

- OR -

> Not at all.
> This would be a lot of work for the benefit of a tiny audience: the 
> disturbed people who hate [non-free] so much that they cannot accept even 
> that [any non-free software] is installed on their computers.

I suspect that having the archive split into main/contrib/non-free
involves a non-trivial amount of work.  Yet Debian as a project, to
serve its users and derivatives, undertakes the work.

As has already been pointed out by others, if someone is interested in
doing the work and it is not too invasive or disruptive to other parts
of Debian, then it should be done.

That said, I find that your characterization of someone not wanting
systemd installed on their system as "disturbed" to itself be somewhat
disturbing.  You cannot possibly know what grounds someone might have
for not wanting systemd, and to automatically and universally
characterize that as "disturbed" implies a value judgment that runs
counter both to the freeness and universailty that Debian as a project
espouses.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Bug#886238: Please introduce official nosystemd build profile

[Attila Kinali]

On Wed, 3 Jan 2018 14:25:03 +0100
m...@linux.it (Marco d'Itri) wrote:

> This would be a lot of work for the benefit of a tiny audience: the 
> disturbed people who hate systemd so much that they cannot accept even 
> that libsystemd is installed on their computers.

And insults like this is why a lot of people stopped discussing
anything with systemd zealots.

Attila Kinali
-- 
It is upon moral qualities that a society is ultimately founded. All 
the prosperity and technological sophistication in the world is of no 
use without that foundation.
 -- Miss Matheson, The Diamond Age, Neil Stephenson

Bug#886238: Please introduce official nosystemd build profile

[Paul R. Tagliamonte]

Conversely, if the patches are invasive and unmaintainable, its not on
Debian to merge them.

On Jan 3, 2018 9:09 AM, "Wouter Verhelst"  wrote:

On Wed, Jan 03, 2018 at 01:59:05PM +0100, Andrew Shadura wrote:
> Hi,
>
> On 3 January 2018 at 13:12, Hleb Valoshka <375...@gmail.com> wrote:
> > Package: general
> > Severity: wishlist
> >
> > 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.
>
> Do we really need systemd-less builds? I'm not convinced this is
> something relevant to Debian.

We don't *need* them, but it's not a problem if people want to support
it. Debian has always allowed things to be defined by those that want to
do the work.

If adding an official "nosystemd" build profile makes life easier for
people who want to support systemd-less builds, and they send patches to
keep the build profile actually working, then that doesn't hurt us in
any way and I think we should do it.

--
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#886238: Please introduce official nosystemd build profile

[Wouter Verhelst]

On Wed, Jan 03, 2018 at 01:59:05PM +0100, Andrew Shadura wrote:
> Hi,
> 
> On 3 January 2018 at 13:12, Hleb Valoshka <375...@gmail.com> wrote:
> > Package: general
> > Severity: wishlist
> >
> > 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.
> 
> Do we really need systemd-less builds? I'm not convinced this is
> something relevant to Debian.

We don't *need* them, but it's not a problem if people want to support
it. Debian has always allowed things to be defined by those that want to
do the work.

If adding an official "nosystemd" build profile makes life easier for
people who want to support systemd-less builds, and they send patches to
keep the build profile actually working, then that doesn't hurt us in
any way and I think we should do it.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#886238: Please introduce official nosystemd build profile

[Marco d'Itri]

On Jan 03, Andrew Shadura  wrote:

> Do we really need systemd-less builds? I'm not convinced this is
> something relevant to Debian.
Not at all.
This would be a lot of work for the benefit of a tiny audience: the 
disturbed people who hate systemd so much that they cannot accept even 
that libsystemd is installed on their computers.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#886238: Please introduce official nosystemd build profile

[Jonas Smedegaard]

Quoting Andrew Shadura (2018-01-03 13:59:05)
> Hi,
> 
> On 3 January 2018 at 13:12, Hleb Valoshka <375...@gmail.com> wrote:
> > Package: general
> > Severity: wishlist
> >
> > 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.
> 
> Do we really need systemd-less builds? I'm not convinced this is
> something relevant to Debian.

Arguably we need no documentation-less or testing-less builds either.

The proposal is a help to some of our users.

We support "vendor" mechanisms already as part of our packaging, I see 
nothing wrong in also supporting builds flags that we do not strictly 
need for our "own" builds.  It would still be up to each package 
maintainer if they would take the burden of maintaining added complexity 
to their build routines.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#886238: Please introduce official nosystemd build profile

[Samuel Thibault]

Andrew Shadura, on mer. 03 janv. 2018 13:59:05 +0100, wrote:
> On 3 January 2018 at 13:12, Hleb Valoshka <375...@gmail.com> wrote:
> > Package: general
> > Severity: wishlist
> >
> > 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.
> 
> Do we really need systemd-less builds? I'm not convinced this is
> something relevant to Debian.

Well, if Debian wants to remain relevant to downstreams, it'd be better
to accomodate their needs.

Samuel

Bug#886238: Please introduce official nosystemd build profile

[Simon McVittie]

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
(),
which seems like it isn't a great fit for omission of systemd support:
if a package installs systemd units, links to libsystemd, etc., it's
usually because it causes a functional difference to that package's
behaviour on systems that booted with systemd as pid 1, or on systems
where `systemd --user` is available.

The speculation about a possible nosystemd profile in
 is
not consistent with that design principle. If a package contains systemd
units or uses of libsystemd, then it's safe to assume they were added
for a reason. Whether you value that reason or not, it's nearly always
true to say that cutting out systemd-related bits is a functional change.

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?

(Clearly, that would be a silly thing to do, because if you care about
avoiding systemd enough to be specially rebuilding packages, then you
certainly shouldn't boot with systemd as your process 1; but there's no
technical restriction that prevents that from happening.)

smcv

Bug#886238: Please introduce official nosystemd build profile

[Andrew Shadura]

Hi,

On 3 January 2018 at 13:12, Hleb Valoshka <375...@gmail.com> wrote:
> Package: general
> Severity: wishlist
>
> 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.

Do we really need systemd-less builds? I'm not convinced this is
something relevant to Debian.

-- 
Cheers,
  Andrew

Bug#886238: Please introduce official nosystemd build profile

[Hleb Valoshka]

Package: general
Severity: wishlist

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.