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: Bug#886238: Please introduce official nosystemd build profile

[Russ Allbery]

Sam Hartman  writes:

> Russ, I'm somewhat confused by the above.
> It sounds like Debian as a whole is fairly OK with dependencies on
> libsystemd0 etc.
> We want systems to run without systemd as pid 1 but we don't mind
> systemd libraries being installed.

> I thought the point here was to provide build profiles for building
> without depending on the systemd libraries.
> I don't understand why Debian itself would want that?

The discussion has forked into a serious discussion about how to enable
software to run properly without systemd being PID 1, and a separate
discussion about attempting to build without libsystemd.

The latter serves no actual purpose that anyone can discern other than
getting software to build on systems where libsystemd doesn't exist at all
(Hurd, etc.), which currently is already largely solved via architecture
exclusions and arguably even better solved via libsystemd-dummy (which
already exists but needs some love).  My impression was that we'd already
put that discussion mostly to rest.

I was therefore remarking on the former point: how to enable software to
run properly without systemd being PID 1, something that Debian also
wants, and for which a build profile seems like a very poor fit.

-- 
Russ Allbery (r...@debian.org)   

Re: Bug#886238: Please introduce official nosystemd build profile

[Sam Hartman]

> "Russ" == Russ Allbery  writes:


Russ, I'm somewhat confused by the above.
It sounds like Debian as a whole is fairly OK with dependencies on
libsystemd0 etc.
We want systems to run without systemd as pid 1 but we don't mind
systemd libraries being installed.

I thought the point here was to provide build profiles for building
without depending on the systemd libraries.
I don't understand why Debian itself would want that?

--Sam

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 

Re: Bug#886238: Please introduce official nosystemd build profile

[Russ Allbery]

Wookey  writes:

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

That seems to be another good reason to not take this path, since we want
to support non-systemd systems *in Debian*, not just for some downstream.
So if we figure out how to build a version of a package for such systems,
we want to upload it to our main archive so that Debian users can use it.

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

Only if upstream never, ever wants to use them, yes?  In which case, it
seems like a very *odd* way to upstream patches.  Normally the goal of
upstreaming packages is to allow upstream to, er, use them.

-- 
Russ Allbery (r...@debian.org)   

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

Bug#886238: closed by Bastian Blank <wa...@debian.org> (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: closed by Bastian Blank <wa...@debian.org> (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 <wa...@debian.org> (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 <wa...@debian.org> (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 <wa...@debian.org> (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 <wa...@debian.org> (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

Re: Bug#886238: closed by Bastian Blank <wa...@debian.org> (Re: Bug#886238: Please introduce official nosystemd build profile)

[Alec Leamas]

On 07/01/18 22:41, Hleb Valoshka wrote:

> Have you sent the same warnings to your mates from LP fanclub 

Please, stop this. This is the Debian devel list, and personal opinions
about Lennart Poettering (or anyone else) IMHO just have no place here.

Time to create a new list systemd-flamewars?


Cheers!
--ale

Bug#886238: closed by Bastian Blank <wa...@debian.org> (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.

Re: Bug#886238: Please introduce official nosystemd build profile

[Simon McVittie]

On Sun, 07 Jan 2018 at 18:55:28 +0100, Thomas Goirand wrote:
> IMO, [a nosystemd profile] is a relevant bug because of non-Linux
> ports. If it existed, it would probably make sense for those buildd
> to always select the nosystemd profile when building, which would make
> life easier.

We can already build packages differently for the non-Linux ports; that
was true long before build-profiles were implemented. The work required
for a package maintainer to not build systemd code paths on the non-Linux
ports is no greater than the work required for a package maintainer to
not build systemd code paths under a particular build profile. I really
don't see how that helps the non-Linux ports.

(Arguably a header-only stub version of libsystemd containing static
inline functions that always return "no systemd here"[0] is simpler
still, though, and at some point I should try out that approach when
building src:dbus for the non-Linux ports and see how it compares. I'd
also recommend that approach to developers of derivatives that don't have
systemd; that would avoid the need to patch a significant proportion of
libsystemd users.)

However, disabling "systemd stuff" (whatever that means specifically)
seems a poor fit for how build profiles are designed to be used. The
only interpretations I can think of for a nosystemd profile would
make functional changes to the contents of the package on [linux-any]
architectures (namely, removing systemd integration that would normally
be present). This would have to either:

- violate the usual design principle[1] that activating a
  (non-package-specific) build profile produces a functionally equivalent
  package, requiring bootstrapping infrastructure to special-case that
  profile[2]

or

- require intrusive changes (a new foo-nosystemd package alongside foo)
  to every package where that build profile was used[2]

Neither is particularly appealing.

smcv

[0] https://anonscm.debian.org/cgit/users/md/libsystemd-dummy.git
[1] https://wiki.debian.org/BuildProfileSpec#Profile_built_binary_packages,

https://lists.debian.org/msgid-search/20180103133055.gb5...@perpetual.pseudorandom.co.uk
[2] 
https://lists.debian.org/msgid-search/151500748931.32386.8459340540929450089@localhost

Re: Bug#886238: Please introduce official nosystemd build profile

[Marco d'Itri]

On Jan 07, Thomas Goirand  wrote:

> > duplicates that code. The correct response to a patch to build without
> > libsystemd is "no, that's what libsystemd exists for".
> Does this approach also work for non-Linux ports?
Yes, as long as somebody would bother to update the libsystemd-dummy 
package.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Bug#886238: Please introduce official nosystemd build profile

[Thomas Goirand]

On 01/04/2018 01:33 AM, Josh Triplett wrote:
> Building without *libsystemd*, on the other hand, *is* invasive,
> precisely because libsystemd *already* includes the necessary code to
> handle systems without systemd, and building without libsystemd
> duplicates that code. The correct response to a patch to build without
> libsystemd is "no, that's what libsystemd exists for".

Does this approach also work for non-Linux ports?

Cheers,

Thomas Goirand (zigo)

Re: Bug#886238: Please introduce official nosystemd build profile

[Thomas Goirand]

On 01/03/2018 08:01 PM, Steve Langasek wrote:
> Catering to fanatics who insist on treating it specially, without technical
> merit, has no bearing on the freeness or universality of Debian.

Probably, though IMO if your sentence can in some degree be socially
correct (aren't we all tired of those fanatics?), it may also be
technically irrelevant. I still feel it's probably a sensitive thing to
do. See below.

On 01/03/2018 10:34 PM, Simon Richter wrote:
> Keep in
> mind we just had a discussion last week if it was truly a bug if a
> package fails to work if systemd is not present.

IMO, it is a relevant bug because of non-Linux ports. If it existed, it
would probably make sense for those buildd to always select the
nosystemd profile when building, which would make life easier.

> For that alone, the build profile is useful.

If adding my sentence above, then yes.

Cheers,

Thomas Goirand (zigo)

Re: Bug#886238: Please introduce official nosystemd build profile

[Ansgar Burchardt]

Simon McVittie writes:
> On Sun, 07 Jan 2018 at 00:27:15 +0100, Ansgar Burchardt wrote:
>> sysvinit probably only stays in testing because systemd
>> depends on sysv-rc for compatability with LSB init scripts...
>
> I think it did during the default init system transition, but it doesn't
> any more.
>
> 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.

Oh, right, I somehow ended up thinking the LSB init script bits from
lsb-base were part of sysvinit, but they aren't.

> sysv-rc and initscripts are both present on about 72% of installations
> that report to popcon, even though systemd-sysv is present on about 78%
> of those installations and sysvinit-core is present on less than 2%.
> I don't know what's going on in the other 20% - surely they can't all
> be wheezy or older? Perhaps some of them are chroots or containers with
> no init system at all?

If you look at the version graph at https://popcon.debian.org (leaving
out intermediate versions):

1.28 (sarge)  : 16
1.41 (etch)   : 740
1.46 (lenny)  : 2442
1.49 (squeeze): 7912
1.56 (wheezy) : 27436

total submissions : 195697

This makes about 20% running wheezy or older releases.

Ansgar

Re: Bug#886238: Please introduce official nosystemd build profile

[Simon McVittie]

On Sun, 07 Jan 2018 at 00:27:15 +0100, Ansgar Burchardt wrote:
> sysvinit probably only stays in testing because systemd
> depends on sysv-rc for compatability with LSB init scripts...

I think it did during the default init system transition, but it doesn't
any more.

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.

Other binary packages from src:sysvinit also have a disproportionately
high popcon score because they used to be Essential, and are not
always auto-removed when no longer used, which keeps them in the key
packages list.

sysv-rc and initscripts are both present on about 72% of installations
that report to popcon, even though systemd-sysv is present on about 78%
of those installations and sysvinit-core is present on less than 2%.
I don't know what's going on in the other 20% - surely they can't all
be wheezy or older? Perhaps some of them are chroots or containers with
no init system at all?

smcv

Re: Bug#886238: Please introduce official nosystemd build profile

[Michael Biebl]

Am 06.01.2018 um 23:35 schrieb Adam Borowski:
> On Sat, Jan 06, 2018 at 07:17:14PM +0100, Marco d'Itri wrote:
>> On Jan 06, Simon Richter  wrote:
>>
>>> As it is now, we have a lot of people who are maintaining their own
>>> packages outside of Debian. Can we get enough support to reintegrate
>>> both the people and the code?
>> I will ignore for the time being the reasons why these packages are 
>> outside of Debian, and focus on the obvious prerequisite.
>> As it is now, and as Simon is patiently trying to explain, sysvinit in 
>> Debian is basically unmaintained because no Debian developer cares 
>> enough about it.
> 
> Ian Jackson and Benda Xu are nobodies?
> (Somehow Ian mistakenly versioned an upload as NMU.)

Afaics sysvinit is basically unmaintained atm given that neither Ian nor
Benda did any significant work on sysvinit in the last year which is why
I reopened #811377

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Bug#886238: Please introduce official nosystemd build profile

[Ansgar Burchardt]

Adam Borowski writes:
> On Sat, Jan 06, 2018 at 07:17:14PM +0100, Marco d'Itri wrote:
>> On Jan 06, Simon Richter  wrote:
>>
>> > As it is now, we have a lot of people who are maintaining their own
>> > packages outside of Debian. Can we get enough support to reintegrate
>> > both the people and the code?
>> I will ignore for the time being the reasons why these packages are 
>> outside of Debian, and focus on the obvious prerequisite.
>> As it is now, and as Simon is patiently trying to explain, sysvinit in 
>> Debian is basically unmaintained because no Debian developer cares 
>> enough about it.
>
> Ian Jackson and Benda Xu are nobodies?
> (Somehow Ian mistakenly versioned an upload as NMU.)

I think Marco wants to suggest that they don't seem to actively maintain
sysvinit and therefore the package is in practice unmaintained.

> I can't think of any pressing issue (#872039 has bogus severity), the
> package is mature, and any recent breakage happened due to systemd
> changes.

No maintainer has replied for almost half a year (when the bug was
filed)...  sysvinit probably only stays in testing because systemd
depends on sysv-rc for compatability with LSB init scripts...

> This is not to say all is fine -- the package really could take some extra
> work, but it is functional.

And the remaining packages of the sysvinit ecosystem are unmaintained
too, for example insserv (#834284) and startpar (#834283).  Or
systemd-shim if you want to consider desktop systems too.

Ansgar

Re: Bug#886238: Please introduce official nosystemd build profile

[Simon McVittie]

On Sat, 06 Jan 2018 at 23:35:09 +0100, Adam Borowski wrote:
> I can't think of any pressing issue (#872039 has bogus severity)

If that's the case, please could someone with a suitably well-informed
opinion downgrade it? (Preferably a maintainer, of course, but failing
that, anyone else who's sure about the correct severity.)

Thanks,
smcv

Re: Bug#886238: Please introduce official nosystemd build profile

[Adam Borowski]

On Sat, Jan 06, 2018 at 07:17:14PM +0100, Marco d'Itri wrote:
> On Jan 06, Simon Richter  wrote:
> 
> > As it is now, we have a lot of people who are maintaining their own
> > packages outside of Debian. Can we get enough support to reintegrate
> > both the people and the code?
> I will ignore for the time being the reasons why these packages are 
> outside of Debian, and focus on the obvious prerequisite.
> As it is now, and as Simon is patiently trying to explain, sysvinit in 
> Debian is basically unmaintained because no Debian developer cares 
> enough about it.

Ian Jackson and Benda Xu are nobodies?
(Somehow Ian mistakenly versioned an upload as NMU.)

I can't think of any pressing issue (#872039 has bogus severity), the
package is mature, and any recent breakage happened due to systemd changes.

This is not to say all is fine -- the package really could take some extra
work, but it is functional.


Meow!
-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.

Re: Bug#886238: Please introduce official nosystemd build profile

[Russ Allbery]

Simon Richter  writes:

> Two well-known DDs chimed in in support, and all replies from DDs to
> critical replies were completely dismissive of the criticism. Previous
> instances of this have been similar.

> What should I tell the people who are now maintaining these packages
> outside of Debian will happen if they return? As of now, I have no
> answer that would not be met with "see, that is why we left."

Did you see the other thread that Adrian Bunk and I were participating
about viable paths forward?

What you're seeing is a project which is quite patient with, and willing
to support, ways to maintain a viable sysvinit infrastructure, or some
replacement with a similar design goal but updated software that solves
some of the newer problems.  But a project that is extremely *impatient*
with grandstanding nonsense that does nothing to achieve these goals and
is just a troll to waste our time, energy, and good will, like trying to
eliminate an inert shared library dependency or relitigate Debian's
default init system discussion.

Yes, this does require some navigation, and there are still raw feelings,
so picking a few people to do some of the social debates who are
reasonably good at it might be a good move.  But you can maintain plenty
of packages in Debian without participating in these debian-devel
discussions at all, and I can assure you that Debian Policy is quite open
to continuing to document and standardize how to build a sysvinit or
similar infrastructure.  There just need to be people to do the actual
work, of course.

It would also be nice if these folks would show a bit of basic politeness
and say thank you to the systemd maintainers, who have been a big part of
keeping an ecosystem alive in Debian that they don't even use, in the face
of a bunch of vitriol, just because it's the right thing to do.

-- 
Russ Allbery (r...@debian.org)   

Re: Bug#886238: Please introduce official nosystemd build profile

[Marco d'Itri]

On Jan 06, Simon Richter  wrote:

> As it is now, we have a lot of people who are maintaining their own
> packages outside of Debian. Can we get enough support to reintegrate
> both the people and the code?
I will ignore for the time being the reasons why these packages are 
outside of Debian, and focus on the obvious prerequisite.
As it is now, and as Simon is patiently trying to explain, sysvinit in 
Debian is basically unmaintained because no Debian developer cares 
enough about it.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Bug#886238: Please introduce official nosystemd build profile

[Simon Richter]

[Possible candidate for a move to debian-project]

Hi,

On 06.01.2018 14:42, Simon McVittie wrote:

> If this is important to you (and when I say "you" here I mean
> everyone who agrees with that statement, not just you personally), then
> src:sysvinit and the ecosystem around it could really benefit from your
> help.

As it is now, we have a lot of people who are maintaining their own
packages outside of Debian. Can we get enough support to reintegrate
both the people and the code?

This is a social more than a technical problem at the moment.

Case in point: the subthread[1] starting with Marco D'Itri's

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

Two well-known DDs chimed in in support, and all replies from DDs to
critical replies were completely dismissive of the criticism. Previous
instances of this have been similar.

What should I tell the people who are now maintaining these packages
outside of Debian will happen if they return? As of now, I have no
answer that would not be met with "see, that is why we left."

   Simon

[1] https://lists.debian.org/debian-devel/2018/01/msg00088.html



signature.asc
Description: OpenPGP digital signature

Re: Bug#886238: Please introduce official nosystemd build profile

[Simon McVittie]

On Sat, 06 Jan 2018 at 05:18:09 +0100, Simon Richter wrote:
> We still need a non-systemd ecosystem for everything that is out of
> scope for systemd.

If this is important to you (and when I say "you" here I mean
everyone who agrees with that statement, not just you personally), then
src:sysvinit and the ecosystem around it could really benefit from your
help. initscripts currently has an RC bug open, its most recent maintainer
upload was almost a year ago, and most of the uploads in the last couple
of years were from systemd maintainers keeping it on life-support;
systemd-shim is unmaintained upstream and in Debian; cgmanager is
unmaintained upstream and RFA in Debian; and libnih is unmaintained
upstream and in Debian (and currently uninstallable and fails to rebuild,
although there's a patch in the BTS for that).

In the longer term, elogind (a standalone fork of systemd-logind)
might well be a more sustainable way to provide systemd-logind APIs on
sysvinit-booted systems than the current approach of combining the current
systemd-logind with systemd-shim, an incomplete emulation of the systemd
manager (pid 1) that needs to keep up with whatever manager APIs logind
currently makes use of. After all, it seems more likely that third-party
software can cope with an old version of the logind APIs than that
systemd-logind can cope with an old version of the systemd manager API,
when logind and the manager are normally part of the same source tree
and so are upgraded together.

Either way, if you want sysvinit (and the stack around it) to continue to
be supported, it's necessary for someone who thinks the same way to do
the work to support it. Expecting the rest of Debian (and in particular
the systemd maintainers, ironically) to keep propping up sysvinit is
not really sustainable.

smcv

Re: Bug#886238: Please introduce official nosystemd build profile

[Simon Richter]

Hi,

Am 04.01.2018 um 05:12 schrieb Russ Allbery:

> I think the key to a good path forward is to recognize that systemd solved
> some specific problems, and to build a roadmap of which problems do indeed
> need to be solved and the alternate solutions to them, and which aren't
> important enough to folks who don't like systemd to solve and therefore
> will stay systemd-exclusive features until that changes.  Then there can
> be a sustained ecosystem, with a clear mission, alongside systemd, and
> Debian can endeavor to support both.

We still need a non-systemd ecosystem for everything that is out of
scope for systemd.

I've written a lengthy blog entry[1] about this in 2016. The condensed
argument is that no init system can provide both an imperative and a
descriptive configuration model at the same time unless it solves the
halting problem and resolves the interaction between both configuration
systems. For desktop environments, we need the configuration to be
descriptive and machine writeable, otherwise the configuration dialogs
will not work, but this comes at the price of the flexibility offered by
an imperative language.

Systemd and System V init are two fundamentally different approaches.
Neither can replace the other without breaking core design principles
and becoming completely useless in the process.

   Simon

[1] http://www.simonrichter.eu/blog/2016-03-03-why-sysvinit.html




signature.asc
Description: OpenPGP digital signature

Re: Bug#886238: Please introduce official nosystemd build profile

[Adam Borowski]

On Fri, Jan 05, 2018 at 12:08:42PM +0100, Svante Signell wrote:
> On Fri, 2018-01-05 at 01:47 +0100, Adam Borowski wrote:
> > Especially you two shouldn't be fighting.  As far as I know, Svante is
> > somewhat involved with eudev maintenance in Devuan (done mostly by parazyd,
> > though), while Marco has a great wealth of udev experience.
> 
> Well I did the work an parazyd did commit my patches and issued builds. 
> Question
> is: Who did do the real work?

Thanks for correction.  I made the blind assumption that the Maintainer:
field has at least some accuracy.  I'm used to Debian workflows, not
Devuan's.

If the whole credit goes to you, good!

> > eudev is currently not needed for Debian, but it's good to have ready and
> > tested packages we can import when/if udev becomes systemd only (which can
> > happen at any moment as its upstream we don't control).
> 
> I really doubt Debian would accept eudev and elogind into their repositories.

Actually, Simon McVittie described a proposal that KatolaZ opined as not
merely acceptable but "a great solution".  It would allow every Debian
package that currently depends on libpam-systemd to be usable on Devuan
without even recompiling, much less a sourceful change -- all while handling
future compat breaks sanely.  I'll see how I can assist.

As for eudev, the only group who can deny a package into the archive are the
ftpmasters, although being useful wrt dependencies is another matter.  If
you think strongly about having such standby package ready, I can sponsor
it into experimental -- on the other hand, unless you can show some benefit,
I strongly would advise against having it in unstable, as it'd complicate
the lives of udev maintainers for no clear gain.  They promised to not make
udev systemd only, and I see no reason for them to renege -- the decision
belongs to a person employed by Red Hat, who could make a future release
require systemd.  If that happens, well, _then_ it'd be time to put eudev
into unstable.


Meow!
-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.

Re: Bug#886238: Please introduce official nosystemd build profile

[Svante Signell]

On Fri, 2018-01-05 at 01:47 +0100, Adam Borowski wrote:
> 
> 
> Especially you two shouldn't be fighting.  As far as I know, Svante is
> somewhat involved with eudev maintenance in Devuan (done mostly by parazyd,
> though), while Marco has a great wealth of udev experience.

Well I did the work an parazyd did commit my patches and issued builds. Question
is: Who did do the real work?

> eudev is currently not needed for Debian, but it's good to have ready and
> tested packages we can import when/if udev becomes systemd only (which can
> happen at any moment as its upstream we don't control).

I really doubt Debian would accept eudev and elogind into their repositories. As
you know Debian is no longer "the Universal Operating System". Next in line of
Debian becoming a truly Linux-only distribution would be to throw out Hurd and
kFreeBSD.

Re: Bug#886238: Please introduce official nosystemd build profile

[Jonathan Dowland]

On Thu, Jan 04, 2018 at 10:44:24PM +0300, Hleb Valoshka wrote:

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.


Whehter something has a systemd code path and whether it links to
libsystemd is orthogonal. As smcv has indicated in another post, the
canonical run-time check for systemd is the existence of
/run/systemd/system. No libsystemd is required for that check and it's
conceivable for software to perform systemd-specific functions without
libsystemd. So, if your motivation is to test non-systemd code paths,
this proposal is *not* sufficient for that purpose.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: Bug#886238: Please introduce official nosystemd build profile

[Jonathan Dowland]

On Thu, Jan 04, 2018 at 10:25:14PM +0300, Hleb Valoshka wrote:

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


Perhaps these interested parties should be doing the work to spec/design
the build profile changes that are being requested in Debian.


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


Ansgar does not need to provide proof for this *on debian-devel*. This
has already been covered thoroughly in the distance past on this and
other lists, and is in any case off-topic.


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


As above.


--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: Bug#886238: Please introduce official nosystemd build profile

[Simon McVittie]

On Fri, 05 Jan 2018 at 02:03:56 +0100, Svante Signell wrote:
> On Fri, 2018-01-05 at 00:41 +, Simon McVittie wrote:
> > On Thu, 04 Jan 2018 at 23:01:07 +0100, Svante Signell wrote:
> > > What about creating a linux-nosystemd architecture, e.g.
> > > dbus-1.12.2/debian/control
> > > Build-Depends:
> > >  libsystemd-dev [linux-any !linux-nosystemd]
> > > etc.
> 
> OK, I read you. But you omitted the words about !linux architectures, why?

Again, libsystemd parallels libselinux and libapparmor. Software that
is portable to non-Linux kernels has to support being built without
those libraries because on non-Linux kernels they simply don't exist.
That isn't a particularly compelling reason to not link them (or introduce
new complexity to make it optional to link them) when building
Linux binaries for a general-purpose distribution like Debian.

In some ways it would be conceptually cleaner to
hard-depend on an implementation of the libsystemd
API at compile-time, substituting something like
https://anonscm.debian.org/cgit/users/md/libsystemd-dummy.git on the
non-Linux kernels; but I recognise that taking that approach doesn't
scale particularly well, and I don't think it's really sensible to
create a similar stub for every optional library that is less portable
than the software that uses it.

Devuan could probably benefit from reducing its maintenance effort by
having libsystemd-dummy provide libsystemd-dev even on Linux kernels,
so that fewer packages need sourceful changes.

smcv

Re: Bug#886238: Please introduce official nosystemd build profile

[Svante Signell]

On Fri, 2018-01-05 at 00:41 +, Simon McVittie wrote:
> On Thu, 04 Jan 2018 at 23:01:07 +0100, Svante Signell wrote:
> > What about creating a linux-nosystemd architecture, e.g.
> > dbus-1.12.2/debian/control
> > Build-Depends:
> >  libsystemd-dev [linux-any !linux-nosystemd]
> > etc.

OK, I read you. But you omitted the words about !linux architectures, why?

Re: Bug#886238: Please introduce official nosystemd build profile

[Adam Borowski]

On Fri, Jan 05, 2018 at 01:05:27AM +0100, Svante Signell wrote:
> On Thu, 2018-01-04 at 23:09 +0100, Marco d'Itri wrote:
> > 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...
> 
> Yes _your_ reply is classy. Never heard about a more anti-person ever. I hope
> you are not a DD. That would really lower the Debian DD quality (and 
> reputation)
>  :(

Guys, please stop.  This kind of trolling is not helpful.

Especially you two shouldn't be fighting.  As far as I know, Svante is
somewhat involved with eudev maintenance in Devuan (done mostly by parazyd,
though), while Marco has a great wealth of udev experience.

eudev is currently not needed for Debian, but it's good to have ready and
tested packages we can import when/if udev becomes systemd only (which can
happen at any moment as its upstream we don't control).


Meow!
-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.

Re: Bug#886238: Please introduce official nosystemd build profile

[Simon McVittie]

On Thu, 04 Jan 2018 at 23:01:07 +0100, Svante Signell wrote:
> What about creating a linux-nosystemd architecture, e.g.
> dbus-1.12.2/debian/control
> Build-Depends:
>  libsystemd-dev [linux-any !linux-nosystemd]
> etc.

We've never applied such drastic measures for other small libraries that
enable optional features, even when the size of Debian was a much larger
proportion of typical storage media than it is now.

dbus is a nice example so I'll stick with it. It also depends on
libapparmor and libselinux, and it's literally impossible[1] for both of
those libraries to be useful on the same Debian machine; but dbus-daemon
depends on them anyway, because the benefit for people who use the
appropriate LSM is significant, and the cost to everyone else is
trivially small.

libsystemd is no different. It's a library that is relevant on some
system configurations, and does basically nothing on others. Debian is
a binary distribution, so we enable the majority of optional features
at build-time to maximize the applicability of our binaries.

If you want proponents of continued support for non-systemd init to be
taken seriously, I would recommend treating libsystemd as part of the
price you pay for using generic binaries that came from a general-purpose
distribution's buildd, just like libapparmor (if you don't use AppArmor)
and libselinux (if you don't use SELinux). I'm sure you wouldn't want
to create the (hopefully false) impression that opposition to systemd
is based on superficial appearances more than on technical considerations.

Here are some examples of more constructive/less negative ways that
Debian contributors could improve the state of traditional init systems,
if that's something they are interested in putting work into:

* maintain init systems (I notice initscripts currently has a
  release-critical bug open)
* evaluate alternatives to systemd-logind that achieve the same goals
  without requiring systemd as pid 1 (elogind looks promising)

I'm trying hard to be even-handed, assume good faith, and not get into
an "us vs. them" mindset, but every time I find myself reading a thread
like this, that gets a bit harder to do. If threads like this frustrate
enough people, there's a risk that they'll tilt the project consensus
towards considering the cost of choice of init system to exceed the
benefit, and dropping support for non-systemd inits altogether, which
is presumably not what you want to happen.

smcv

[1] until "LSM stacking" is implemented in the kernel, which I hear will
happen any year now

Re: Bug#886238: Please introduce official nosystemd build profile

[Svante Signell]

On Thu, 2018-01-04 at 23:09 +0100, Marco d'Itri wrote:
> 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...

Yes _your_ reply is classy. Never heard about a more anti-person ever. I hope
you are not a DD. That would really lower the Debian DD quality (and reputation)
 :(

Re: Bug#886238: Please introduce official nosystemd build profile

[Svante Signell]

On Thu, 2018-01-04 at 21:35 +0300, Hleb Valoshka wrote:
> 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.

What about creating a linux-nosystemd architecture, e.g.
dbus-1.12.2/debian/control
Build-Depends:
 libsystemd-dev [linux-any !linux-nosystemd]
etc.

There are plenty of packages being built for GNU/Hurd and GNU/kFreeBSD not
depending on *systemd* since it is not available for !linux architectures.

WDYT?

Re: Bug#886238: Please introduce official nosystemd build profile

[Adam Borowski]

On Thu, Jan 04, 2018 at 09:59:12AM +0100, Wouter Verhelst wrote:
> On Thu, Jan 04, 2018 at 04:36:16AM +0100, Adam Borowski wrote:
> > The only reason to avoid libsystemd0 is a cheap way to make sure systemd
> > paths are not used; some packages (I forgot which) have regressions when
> > compiled with systemd support as they detect its presence at compile time
> > rather than runtime.
> 
> Those sound like bugs though. Did you file them?

The utopia stack currently hard-depends on systemd; I haven't tested a
_partially_ rebuilt set of packages in quite a while (since The Great
Flamewar, which happened just before jessie freeze, to be exact) -- at that
time, even well-tested patches were routinely rejected with angry messages,
so I didn't bother and just started my private repository, which is fully
rebuilt.  I was also not a DD at the time.

It'd be good to look for such regressions, but not right now -- a change to
elogind, consolekit65536 (I lost track of its forks), loginkit or Parabola's
notsystemd would invalidate such findings anyway.  I'll poke some folks who
can help evaluate the alternatives.

Doing such research myself would require learning a lot about logind, and
that'd require tuits I need for playing with a yet another random SoC,
molesting an obscure terminal font's upstream about license or trying to get
a controversial patch past Al Viro :p.


Meow!
-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.

Re: Bug#886238: Please introduce official nosystemd build profile

[Philipp Kern]

On 01/04/2018 08:44 PM, Hleb Valoshka wrote:
> "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 suggest that you take your vitriol elsewhere, not to Debian lists.

Kind regards and thanks
Philipp Kern



signature.asc
Description: OpenPGP digital signature

Re: Bug#886238: Please introduce official nosystemd build profile

[Simon McVittie]

On Thu, 04 Jan 2018 at 04:36:16 +0100, Adam Borowski wrote:
> * utopia stack (policykit and friends) which have a hard dependency on
>   systemd

policykit-1 depends on libpam-systemd, which is currently how you spell
"requires a working systemd-logind" in Debian dependencies. systemd-logind
is part of systemd.deb, and requires something that looks a bit like
systemd, either the real systemd as pid 1 or systemd-shim.

> * dependencies on libpam-systemd (including "mere" Recommends, which make
>   apt force an init switch or abort an upgrade without a workaround obvious
>   to an user who doesn't know what to look for)

Many of these are more about having a working systemd-logind (an improved
ConsoleKit replacement) than they are about having systemd as pid 1:
they need to be able to identify and enumerate user sessions, and match
processes to sessions. If there's a good alternative to systemd-logind
for that purpose, they could talk to that instead.

It looks as though elogind is a fork of systemd-logind with reduced
functionality, no dependency on systemd as pid 1, and logind's D-Bus API
(so, basically systemd-shim done right), so it should be possible for
most of those to talk to elogind's logind-compatible API without code
changes (via libsystemd, even). Now that we have versioned Provides,
one way to achieve that might be for implementations of the logind API
to add Provides: logind (= v) where v is the version of systemd whose
logind API is implemented (currently 219 for elogind and 236 for systemd),
and for depending packages to depend on libpam-systemd (>= v) | logind
(>= v), or even on default-logind | logind (>= v) (with default-logind
provided by libpam-systemd on Debian) to be nice to anti-systemd
derivatives. Obviously >= v can be omitted if recent logind features
are not required.

A few packages do genuinely need systemd as pid 1, or `systemd --user`
as an init-like service manager for user sessions (which in turn requires
both systemd as pid 1 and systemd-logind). dbus-user-session is an example
of a package that requires the `systemd --user` service manager. Packages
in this category are unlikely to be ported to not-systemd, unless the
chosen non-systemd infrastructure grows a lot of functionality that is
basically systemd with the bike shed painted a different colour.

smcv

Re: Bug#886238: Please introduce official nosystemd build profile

[Wouter Verhelst]

On Thu, Jan 04, 2018 at 04:36:16AM +0100, Adam Borowski wrote:
> The only reason to avoid libsystemd0 is a cheap way to make sure systemd
> paths are not used; some packages (I forgot which) have regressions when
> compiled with systemd support as they detect its presence at compile time
> rather than runtime.

Those sound like bugs though. Did you file them?

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

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

Re: Bug#886238: Please introduce official nosystemd build profile

[Russ Allbery]

Adam Borowski  writes:

> -shim is moribund (and never worked right even when it was maintained),
> thus installing it on systems with modular inits is damage.  I believe
> this is the problem that should be solved first -- because all
> non-trivial cases mentioned above use logind or an equivalent, and to
> implement a profile you need to know what alternate dependency to use.

> The name I hear the most is elogind, but other options also get
> mentioned.  It'd be good if someone more knowledgeable could say more; I
> think multiple Debian derivatives are experimenting here.

> Once such a solution is chosen, implemented and tested, only then it'll
> be time to fix dependencies -- inside Debian rather than some
> derivative.

I think this would be great.  It's both meaningful and useful in creating
more ecosystem diversity.  I'd be happy to take patches for this sort of
thing as a maintainer, and I think it's a much better use of people's
energy and good will.

I think the key to a good path forward is to recognize that systemd solved
some specific problems, and to build a roadmap of which problems do indeed
need to be solved and the alternate solutions to them, and which aren't
important enough to folks who don't like systemd to solve and therefore
will stay systemd-exclusive features until that changes.  Then there can
be a sustained ecosystem, with a clear mission, alongside systemd, and
Debian can endeavor to support both.

And the resulting tools, assuming they're built in the small pluggable
tool model (seems like a likely bet) would be broadly useful even for
those of us who like systemd.  For example, I'd love something that can do
the jailing and seccomp rule configuration that systemd can do, with the
same or very similar syntax and, particularly, the syscall groupings, but
that is implemented as a standalone wrapper program that I can use in
situations where I don't want to spawn a service.

-- 
Russ Allbery (r...@debian.org)   

Re: Bug#886238: Please introduce official nosystemd build profile

[Adam Borowski]

On Wed, Jan 03, 2018 at 09:55:44AM -0800, Russ Allbery wrote:
> Hleb Valoshka <375...@gmail.com> writes:
> 
> > 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.
> 
> If this is about avoiding linking with libsystemd, I think this is
> unbelievably silly and a completely waste of maintainer time and emotional
> energy.

Yeah -- and, unlike most people in this thread, I do maintain a repository
which does that:

deb https://angband.pl/debian nosystemd-buster main
deb-src https://angband.pl/debian nosystemd-buster main
(instructions and key at https://angband.pl/deb/archive.html)

The only reason to avoid libsystemd0 is a cheap way to make sure systemd
paths are not used; some packages (I forgot which) have regressions when
compiled with systemd support as they detect its presence at compile time
rather than runtime.

> I'm one of the people who has been advocating for continuing to support
> systems without systemd running.  I think that's both meaningful and
> important.  Avoiding linking with a shared library that does nothing when
> systemd is not running is neither meaningful nor important.  Please do not
> squander other people's good will on trivia like this.

While libsystemd0 is indeed harmless, there are cases where such a build
profile would be worthwhile:
* utopia stack (policykit and friends) which have a hard dependency on
  systemd
* dependencies on libpam-systemd (including "mere" Recommends, which make
  apt force an init switch or abort an upgrade without a workaround obvious
  to an user who doesn't know what to look for)

On the other hand, rebuilding with a build profile is useful only for
derivatives.  What about looking for a solution that would help users of
unmodified Debian instead?

-shim is moribund (and never worked right even when it was maintained),
thus installing it on systems with modular inits is damage.  I believe this
is the problem that should be solved first -- because all non-trivial cases
mentioned above use logind or an equivalent, and to implement a profile you
need to know what alternate dependency to use.

The name I hear the most is elogind, but other options also get mentioned.
It'd be good if someone more knowledgeable could say more; I think multiple
Debian derivatives are experimenting here.

Once such a solution is chosen, implemented and tested, only then it'll be
time to fix dependencies -- inside Debian rather than some derivative.


Meow!
-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.

Re: Bug#886238: Please introduce official nosystemd build profile

[Simon McVittie]

On Wed, 03 Jan 2018 at 22:34:01 +0100, Simon Richter wrote:
> On 03.01.2018 20:01, Steve Langasek wrote:
> > What a nosystemd build profile proposes to do is to avoid linking against
> > *lib*systemd, which is an inert library dependency whose runtime impact
> > rounds to zero when systemd is not in use.
> 
> The build profile is useful where upstream source can be configured in
> different ways, e.g. because someone wrote a daemon that works on BSD
> and can optionally activate "systemd mode" with additional integration
> code.

dbus-daemon in src:dbus is one such daemon (and one for which Devuan
appears to have a patched version).

On non-systemd Linux, dbus-daemon works the same way it always did;
on Linux with systemd, it works a bit better than that. The runtime
checks before doing something systemd-related (canonically: probe whether
/run/systemd/system exists) are not difficult.

A few features that are in practice very strongly correlated with systemd
(those that rely on XDG_RUNTIME_DIR) don't explicitly check for systemd,
so they would also work on non-systemd (and even non-Linux) systems if
someone else put the work into providing an XDG_RUNTIME_DIR that meets
the specification.

There is no point in packaging dbus for Linux other than "in systemd
mode": the only difference for a non-systemd machine is an amount of
extra disk space that, as Steve said, rounds to zero. (Obviously it's
still built "in non-systemd mode" on the non-Linux kernels, where the
systemd-related build-dependencies are absent.)

> My expectation at this point is "if it has a 'nosystemd' profile, then
> at least it has probably been tested to work without systemd."

Build profiles are not a Features field. Ideally, packages work with or
without systemd without having to be compiled differently, the same way
they might work with X11 or Wayland, or with ALSA or PulseAudio, without
having to be compiled differently. In Debian, we conventionally enable
all possible features unless they conflict or are otherwise problematic;
"better systemd integration" is one such feature, and can usually be
enabled without altering the behaviour of non-systemd systems.

We currently expect packages to work with either a separate or a merged
/usr; extrapolating from what you've said about nosystemd would lead
to us having a usrmerge or nousrmerge build profile to signal that
(depending which the default/more-tested case is considered to be), but
we don't. Similarly, we don't have build profiles for whether the package
works with {dash,bash,posh,mksh,busybox} as /bin/sh, or for whether the
package works on Wayland, or Mir, or non-UTF-8 locales, or all sorts of
other situations that might be considered unusual or non-standard.

> we just had a discussion last week if it was truly a bug if a
> package fails to work if systemd is not present

I'd say it's certainly a bug if it fails to work and doesn't have
a Depends: or Recommends: on systemd-sysv. (Recommends because in
principle you might be booting systemd as pid 1 without it actually
being /sbin/init.) As long as Debian supports non-systemd init, asking a
maintainer to document the dependency seems reasonable, even if they're
unwilling or unable to change the code to avoid it (for instance that
seems vanishingly unlikely to happen for dbus-user-session, and is
clearly not sensible at all for systemd-cron or runit-systemd because
working with systemd is their entire purpose).

Now, I'm sure there are packages that have an undeclared dependency on
systemd; but there are also lots of packages with other unreported bugs,
so this isn't unusual.

smcv

Re: Bug#886238: Please introduce official nosystemd build profile

[Josh Triplett]

Wouter Verhelst 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.
>
> Yes. But adding a "nosystemd" build profile is in no way "invasive and
> unmaintainable".

"nosystemd" doesn't require a build profile. If you don't want systemd
installed, you can install sysvinit or another init system instead, and
remove systemd.

Building without *libsystemd*, on the other hand, *is* invasive,
precisely because libsystemd *already* includes the necessary code to
handle systems without systemd, and building without libsystemd
duplicates that code. The correct response to a patch to build without
libsystemd is "no, that's what libsystemd exists for".

(If someone feels like inviting flames upon themselves, I'd suggest
retitling this bug to s/nosystemd/nolibsystemd/, to make it clearer what
the request is.)

Re: Bug#886238: Please introduce official nosystemd build profile

[Simon Richter]

Hi,

On 03.01.2018 20:01, Steve Langasek wrote:

> What a nosystemd build profile proposes to do is to avoid linking against
> *lib*systemd, which is an inert library dependency whose runtime impact
> rounds to zero when systemd is not in use.

I don't really care about a bit of dead weight except on very small
embedded systems, of which I have precisely one left.

The build profile is useful where upstream source can be configured in
different ways, e.g. because someone wrote a daemon that works on BSD
and can optionally activate "systemd mode" with additional integration
code. There is still a large free software movement outside the
Linux+systemd world, after all.

My expectation at this point is "if it has a 'nosystemd' profile, then
at least it has probably been tested to work without systemd." Keep in
mind we just had a discussion last week if it was truly a bug if a
package fails to work if systemd is not present.

For that alone, the build profile is useful.

   Simon



signature.asc
Description: OpenPGP digital signature

Re: Bug#886238: Please introduce official nosystemd build profile

[Steve Langasek]

On Wed, Jan 03, 2018 at 09:46:59AM -0500, Roberto C. Sánchez wrote:

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

You don't need a separate build profile in order to not install systemd. 
That is already supported.

What a nosystemd build profile proposes to do is to avoid linking against
*lib*systemd, which is an inert library dependency whose runtime impact
rounds to zero when systemd is not in use.

Treating libsystemd specially, out of all the mostly-unused libraries that
get linked in the archive, is not sensible.

Catering to fanatics who insist on treating it specially, without technical
merit, has no bearing on the freeness or universality of Debian.

-- 
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: Bug#886238: Please introduce official nosystemd build profile

[Russ Allbery]

Hleb Valoshka <375...@gmail.com> writes:

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

If this is about avoiding linking with libsystemd, I think this is
unbelievably silly and a completely waste of maintainer time and emotional
energy.

I'm one of the people who has been advocating for continuing to support
systems without systemd running.  I think that's both meaningful and
important.  Avoiding linking with a shared library that does nothing when
systemd is not running is neither meaningful nor important.  Please do not
squander other people's good will on trivia like this.

-- 
Russ Allbery (r...@debian.org)   

Re: Bug#886238: Please introduce official nosystemd build profile

[Andrey Rahmatullin]

On Wed, Jan 03, 2018 at 03:40:06PM +0100, Attila Kinali wrote:
> And insults like this is why a lot of people stopped discussing
> anything with systemd zealots.
So win-win?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Bug#886238: Please introduce official nosystemd build profile

[Andrey Rahmatullin]

On Wed, Jan 03, 2018 at 09:46:59AM -0500, Roberto C. Sánchez 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.
Indeed, this is amusingly similar to the recent Ian's proposal.

> 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.
There are two kinds of reasons why we do the separation. One is not
relevant to "cannot accept even that [any non-free software] is installed"
and another is, indeed, wrong.

> That said, I find that your characterization of someone not wanting
> systemd installed on their system as "disturbed" to itself be somewhat
> disturbing. 
You are confusing libsystemd with systemd (and installed with enabled).

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Bug#886238: Please introduce official nosystemd build profile

[Michael Stone]

On Wed, Jan 03, 2018 at 02:24:27PM +, Colin Watson wrote:

It would be of some benefit to the rest of us because we could probably
stop having conversations about it more quickly by pointing to the build
profile ...


That seems overly optimistic at best.

Mike Stone

Re: Bug#886238: Please introduce official nosystemd build profile

[Colin Watson]

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.

It would be of some benefit to the rest of us because we could probably
stop having conversations about it more quickly by pointing to the build
profile ...

-- 
Colin Watson   [cjwat...@debian.org]

Re: Bug#886238: Please introduce official nosystemd build profile

[Wookey]

On 2018-01-03 13:59 +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.

It's relevant to downstream distros that exclude systemd. I assume
such things exist. And we do our best to support downstream changes
that are integrateable, which is why we have things like dpkg-vendor
and ubuntu-patches. In this case a profile probably does make sense
becuse dpkg-vendor (nominally a more appropriate mechanism) can only
adjust build-time actions, not build-dependencies, and in this case I
expect that build-dependencies need to be changed. 

So no this isn't relevant to debian the distro, but it is relevant the
Debian the ecosystem. 

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


signature.asc
Description: PGP signature