[PATCH 00/12] RFC: util-linux: one package per binary

* [PATCH 00/12] RFC: util-linux: one package per binary
@ 2019-01-14 12:56 André Draszik
  2019-01-14 12:56 ` [PATCH 01/12] util-linux: simplify version upgrades (MAJOR_VERSION) André Draszik
                   ` (16 more replies)
  0 siblings, 17 replies; 103+ messages in thread
From: André Draszik @ 2019-01-14 12:56 UTC (permalink / raw)
  To: openembedded-core

This series of patches changes util-linux to splitting into
one package per binary automatically, using do_split_packages()

* the first 5 patches are a general clean-up
* patch 2 could be classed as avoiding a potential crash
* patch 5 is important, as it fixes up some existing packaging
  problems
* the subsequent patches are the actual implementation

The slight 1st problem was that update alternatives was running
right after copying from D to PKGD, and at that point in time
PACKAGES and ALTERNATVE_xxx were expected to be fully populated.
So I changed this slightly, so that util-linux can generate
PACKAGES now right after perform_packagecopy(), but before
update-alternatives processing.

The small 2nd problem was that FILES_${PN} must reference the
renamed file name (after update-alternatives has run). Given
this is quite hard to do automatically when populating packages
using do_split_packages(), I updated update-alternatives to
update the file name in FILES_${PN} if the non-renamed file
was specified in there.
This would also allow updating all recipes to drop knowledge
about that renaming where this is done at the moment.

Finally, I am splitting up the packages, one commit per directory.

Things to note and questions:
* it is unclear to me why util-linux RDEPENDS vs. RRECOMMENDS some
  of the manually splitted packages before this series, and some
  of those pre-existing packages weren't in RRECOMMENDS or RDEPENDS
  at all.
  For that reason, the RDEPENDS on packages from base_sbindir and
  base_bindir that existed before this series, weren't updated,
  only new packages from those two directories have been added
  to RRECOMMENDS of the meta-package.

  I would suggest to drop all RDEPENDS and simply have util-linux
  RRECOMMENDS *all* the packages, but I don't know the origial
  reasoning for that distinction.

* /etc/default/mountall is the only file remaining in the util-linux
  package. I am not sure what to do with it as I coulnd't find any
  user anyway.
  Can it be dropped altogether, should it be moved into the util-linux-mount
  package instead?
  Note that the util-linux-mount and util-linux-umount existed before
  this series, but /etc/default/mountall was still packaged into
  util-linux.

* The pre-existing util-linux-swaponoff is a meta-package now, that
  simply RDEPENDS on -swapon and -swapoff, simply for backwards
  compatibility reasons, but is it really necessary, given people
  can now add -swapon and -swapoff if they want to.
  No harm in keeping it either, though.

* the -dev package RRECOMMENDS some (but not all) of the split -dev
  packages (which don't necessarily exist), e.g. util-linux-losetup-dev
  Should it RPROVIDE those itself instead? Should those be made
  ALLOW_EMPTY? Should the RRECOMMENDS be tweaked?
  What is the preferred approach here?

^ permalink raw reply	[flat|nested] 103+ messages in thread