Source: libverto
Version: 0.2.4-2.1
Severity: wishlist
X-Debbugs-CC: debian-riscv@lists.debian.org
Tags: patch
User: debian-riscv@lists.debian.org
Usertags: riscv64

Hello,

we are in the process of bootstrapping a Debian port for the
riscv64 architecture (https://wiki.debian.org/RISC-V). The
binary packages libverto-dev and libverto-libev1 are part of the
build-dependency chain for the essential package set, so we need
to cross-build them for riscv64 to be able to complete the
bootstrap process.  Unfortunately it is currently impossible to
cross-build libverto as-is due to the following situation:

The package curently has a "hard" build-dependency on
libglib2.0-dev, which is only needed for building libverto-glib1,
but not for the other binary packages built from the libverto
source package.  For cross-building libverto-glib1, one would
need to install libglib2.0-dev for the host architecture, but
that isn't possible due to components of glib2.0 pulled in by
that not being multiarch-coinstallable with their build-arch
equivalents and debhelper transitively depending on the same
components for the build-arch.

The solution for this issue is adding a pkg.libverto.noglib
build-profile to the package, which disables building the
libverto-glib1 binary package and the corresponding
build-dependency when set. Attached is a patch implementing
that.

It would be great if you could upload a new version of libverto
with the patch applied to unstable soon as we depend on this
for completing our bootstrapping efforts.

Regards,
Karsten

Hello,

I just found that this solves only half of the problem :-/.
Building works fine with the patch, but libverto-dev has a
dependency on libverto-glib1, so it's uninstallable (without
forcing the installation) when libverto-glib1 isn't available.
AIUI, it is technically possible to use libverto-dev without
libverto-glib1 but I understand that you normally want to pull in
all "plugins" such as libverto-glib1.  Would changing the
dependency on libverto-glib1 to a "recommends" be an option?

Regards,
Karsten

this approach seems a bit strange.
Why would we want a package specific build profile rather than excluding
glib from a stage1 build of libverto.

Also, note that I'm about to update to a new version of libverto and
start building for libevent.
I wonder if for bootstrapping we want to pick one single event backend
and build against that in a stage 1 build?

I need to check this, but the probable reason that I included the event
backends in the -dev package is that it is permissible to  link directly
against a plugin.
I think policy strongly implies that if a -dev package is going to have
a .so symlink for a shared library it needs to have a hard depends on
that package.
Obviously we could remove the depends when we're not building against
glib on the glib plugin, although I think that technically means that
the -dev package has different functionality depending on what build
profile is used.
Which I think is problematic for some people's view of the build profile
spec.
I think this may be an argument for revising that.

Thoughts?

On Sun, Mar 11, 2018 at 06:39:34PM -0400, Sam Hartman wrote:

[libverto during arch bootstrap / cross-build problems with glib,
 adding a pkg.libverto.noglib build profile]

Hello,

first many thanks for your quick reply.  This is the first time I
am working on an architecture bootstrap from scratch, so I might
well be misunderstanding things.  What I am trying to achieve is
in fact a "stage1"-style build of libverto.  The way I have
understood the build profile spec is that the "traditional" way
of using DEB_STAGE for stage1-builds had been deprecated and
superseded by defining build-profiles as that (at least in
theory) allows for automatically finding the proper bootstrap
order and solving circular dependencies via use of profiles
purely from package metadata.  AIUI, the first step was using
"stageX" build profiles instead of the DEB_STAGE mechanism, but
according to the text of the build profile spec these are now
also (citation from the spec) "Deprecated.  Use a descriptive
profile below or from the extension namespace instead.  Must
reduce Build-Depends.  Must not be used outside of the very early
cross-compiler bootstrap phase (gcc, glibc, linux)".  As there is
no registered "standard" build profile for avoiding glib, I had
resorted to the "extension namespace" approch, resulting in
proposing a pkg.libverto.noglib profile.

I am not familiar with libverto itself - the first time I have
become aware of its existence at all was when it showed up as a
build-dependency for the "essential" package set that I was
trying to cross-build.  AIUI (please correct me if I'm wrong),
whether picking a single event backend for a stage1 build is
feasible depends on which backend(s) the applications from the
essential set that use libverto actually require.  My primary
target was getting krb5 (itself again a build-dependency of the
"essential" package set) built, and krb5 doesn't need glib, so my
approach was to just drop the glib plugin and leave everyting
else as it was.

AIUI (again please correct me if I misunderstood that) the
"normal" case is that setting a build-profile must not result
in created binary packages differing from a non-profile build.
According to

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

this rule is relaxed for profiles in the "extension namespace"
(pkg.$sourcepackage.$foo), i.e. for profiles in this namespace
"content of individual binary packages may change when activating
this profile".

Regards,
Karsten

So, in general, I think picking  a single event backend should be fine.
Most applications work with all event backends; krb5 certainly does.

I'm fairly uncomfortable with the idea of using an extension package
namespace here though because  it seems like you'll need to break this
cycle on every new bootstrap, and so it seems like you want something
that can be auto-detected or similar.
krb5 took a patch for a stage1 build profile to avoid ldap and libsasl.
It seems like it's desirable to update both krb5 and libvirto to
something modern that makes sense, whatever that is.
I have not been following any of this particularly closely.

tags 785324 + pending
tags 1082732 + pending
close 694449
thanks

Hello,

libverto seems in a slightly sorry state, so uploaded a NMU to
delayed/10 using dgit. I'm attaching the debdiff.

The upload tightens the dependency from libverto plugins on the libverto
library. It generally does not make sense to allow mixing packages built
from different versions of the same source packages in an installation.
Using (= ${binary:Version}) ensures that the plugins always use a
matching library.

The upload also demotes the glib dependency to gio. The glib packaging
was reorganized and now provides a smaller development package that
happens to be sufficient for libverto's use.

Bug #694449 argues about tightening the glib dependency, but it has
become so old by now that the version restriction would be met even in
oldoldstable already. We tend to drop such version constraints
eventually. Therefore, I am closing the bug right away. Additionally,
the reorganization of glib was way after 2.29, so once my NMU is in the
archive, the glib dependency is implicitly tightened.

Additionally, I would like to question Karsten whether #892593 still
applies after this NMU. Since the filing glib has changed heavily. It
now is multiarch coinstallable and due to the demoted glib dependency,
bootstrapping libverto with glib should just work. Karsten, do you agree
that #892593 can be closed without further action?

Please let me know if I should defer the upload any further.

Thanks

Helmut

tags 785324 + pending
tags 1082732 + pending
close 694449
thanks

Hello,

libverto seems in a slightly sorry state, so uploaded a NMU to
delayed/10 using dgit. I'm attaching the debdiff.

The upload tightens the dependency from libverto plugins on the libverto
library. It generally does not make sense to allow mixing packages built
from different versions of the same source packages in an installation.
Using (= ${binary:Version}) ensures that the plugins always use a
matching library.

The upload also demotes the glib dependency to gio. The glib packaging
was reorganized and now provides a smaller development package that
happens to be sufficient for libverto's use.

Bug #694449 argues about tightening the glib dependency, but it has
become so old by now that the version restriction would be met even in
oldoldstable already. We tend to drop such version constraints
eventually. Therefore, I am closing the bug right away. Additionally,
the reorganization of glib was way after 2.29, so once my NMU is in the
archive, the glib dependency is implicitly tightened.

Additionally, I would like to question Karsten whether #892593 still
applies after this NMU. Since the filing glib has changed heavily. It
now is multiarch coinstallable and due to the demoted glib dependency,
bootstrapping libverto with glib should just work. Karsten, do you agree
that #892593 can be closed without further action?

Please let me know if I should defer the upload any further.

Thanks

Helmut