#677 Issue closed: Deb package build issue for supporting arch specific requirements

Labels: enhancement

mmitsugi opened issue at 2015-10-28 14:04:

Hi,
Similar to #629, deb package build arch "all" (noarch package) contradicts arch specific requirements.
Package "syslinux" is only required for intel platform, not ppc platform.
("syslinux" is not available in ppc)

So, we can not create ppc deb package with current deb package build configuration.

To fix this issue, I think there are several options:

option 1:
change deb control file to build arch dependent packages as well as we do against rpm.
it might be painful to build several arch packages in each release.

--- a/packaging/debian/control
+++ b/packaging/debian/control
@@ -5,10 +5,10 @@ Maintainer: Dag Wieers <dag@wieers.com>
 Homepage: http://relax-and-recover.org/

 Package: rear
-Architecture: all
+Architecture: i386 ia64 amd64 ppc64el
 Provides: rear
 Build-Depends: debhelper (>> 5.0.0)
-Depends: mingetty, syslinux, ethtool, libc6, lsb-release, portmap, genisoimage, iproute, iputils-ping, nfs-client, binutils, parted, openssl, gawk, attr
+Depends: mingetty, syslinux[!ppc64el], ethtool, libc6, lsb-release, portmap, genisoimage, iproute, iputils-ping, nfs-client, binutils, parted, openssl, gawk, attr
 Description: Relax and Recover is a bare metal disaster recovery and system
  migration framework. See http://relax-and-recover.org/ for all the details.
  We are still looking for a Debian package maintainer who would write better

option 2:
just move syslinux from "Depends" to "Recommends".
we can keep noarch, but intel platform user will realize that syslinux is required after issuing rear command.

I'm not so familiar with deb package build, but as far as I checked there seems not to be other options.

Let's discuss how we should go.

schlomo commented at 2015-10-28 15:31:

Thanks @mmitsugi for bringing this up. I think that Option 1 (arch specific debs) makes more sense:

  • Follow same strategy as with rpm -> consistent mindset for rpm and deb
  • I don't like Recommends. ReaR should have a hard dependency on the things it actually needs.

jsmeix commented at 2015-10-29 08:44:

@schlomo
I wonder what exactly you mean with "things it [rear] actually needs".
In particular I wonder about the "actually" therein.

I think it can depend very much on the specific system
where rear is running what is actually needed by it.
Here I mean what other programs rear actually calls.

I do not know how to extract from bash scripts
what executables can be called by them
(in a sufficiently reasonable way).

If I knew this I could generate a list of the "callable executables".

Then we could decide which of them are considered to be
mandatory in any case (i.e. RPM requirements) and which
of them are probably only "sometimes called" so that
for the latter RPM recommends might be sufficient.

Think about "usual systems" where chattr is not needed
versus SLE12-SP1 with btrfs where chattr is required, cf.
https://github.com/rear/rear/issues/556#issuecomment-139239652

Should I add e2fsprogs (provides chattr) as RPM requirement
only because SLE12-SP1 with btrfs needs it
(but e.g. SLE12-SP1 with ext4 does not need it)?

Have in mind that RPM requirements are hard requirements
that cannot be ignored or skipped by the admin without
causing that various package management tools
will report that broken dependency all the time.

mmitsugi commented at 2015-11-03 05:50:

Hi I've created option 1 change in #682
Please merge it if there are any objections.

[Export of Github issue for rear/rear.]