kernel-packages team mailing list archive

[Andy Whitcroft <apw@xxxxxxxxxxxxx>]

/me will bring a sample patch set to sprint for this.

** Description changed:

- We need to sort out naming for linux-tools as it is not sensible in the
- face of multiple source packages.
+ The linux tools packages are not currently scalable to multiple source
+ package branches.  This is because the packages are actually per
+ architecture (not flavour) in both contents and naming but may differ
+ between source packages which may be at different versions.  This prevents
+ us safely emitting linux-tools packages from branches other than master.
+ 
+ We have a policy of insulating people from the source package from which a
+ kernel comes.  We do this via the linux-<thing>-<flavour> package naming,
+ which is consistant regardless of overall package.  It therefore makes
+ a lot of sense to extend this to the tools package.  Such that we would
+ have the following user consumable packages as below:
+ 
+     linux-tools-<flavour>		-- tools to match linux-image-<flavour>
+     linux-tools-<abi>-<flavour>		-- tools to match linux-image-<abi>-<flavour>
+ 
+ In order to allow linux-tools to be still be a valid install target the
+ first of these would additionally Provides: linux-tools to allow simple
+ selection of the appropriate flavour specific package where there is only
+ one, or to help the user make an informed choice where there is more.
+ 
+ The first would be the logical choice when wanting to maintain tools
+ installed for all future version of the kernel, mirroring the kernels as
+ installed by the linux-<flavour> and linux-image-<flavour> packages and
+ keeping the user up to date in tools.  The second would be the appropriate
+ package to request installation when trying to target a specific
+ kernel version and would be used by the wrapper when requesting manual
+ intervention such as when the linux-tools-<flavour> is not installed.
+ 
+ The first of these would be added to the appropriate meta package, the
+ second would come out of the flavour specific packages in the main kernel
+ source package.
+ 
+ Further we would then be able to name the actual binary packages as produced by the 
+ various source packages to be source package specific.  Thus we would have packages as
+ below:
+ 
+     linux-tools-<abi>			-- coming out of the master branch
+     linux-grouper-tools-<abi>		-- coming out of the grouper branch
+ 
+ These would be hidden from the user via the previously listed meta packages
+ and would not be direct installation candidates.
+ 
+ There is also an additional linux-tools-common package which represents
+ the manual pages and the wrappers.  These would be only generated and
+ installed from the master branch and all of the other flavours would
+ (at least initially) share this package.
+ 
+ The actual binaries will be moved over to names similar to below:
+ 
+     /usr/lib/<srcpkg>-tools-<abi>/<binary>
+ 
+ with symlinks in as below for each flavour pointing to the above:
+ 
+     /usr/lib/linux-tools/<binary>-<abi>-<flavour>

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1205284

Title:
  linux-tools naming is not scalable to multiple source packages

Status in “linux” package in Ubuntu:
  In Progress

Bug description:
  The linux tools packages are not currently scalable to multiple source
  package branches.  This is because the packages are actually per
  architecture (not flavour) in both contents and naming but may differ
  between source packages which may be at different versions.  This prevents
  us safely emitting linux-tools packages from branches other than master.

  We have a policy of insulating people from the source package from which a
  kernel comes.  We do this via the linux-<thing>-<flavour> package naming,
  which is consistant regardless of overall package.  It therefore makes
  a lot of sense to extend this to the tools package.  Such that we would
  have the following user consumable packages as below:

      linux-tools-<flavour>		-- tools to match linux-image-<flavour>
      linux-tools-<abi>-<flavour>		-- tools to match linux-image-<abi>-<flavour>

  In order to allow linux-tools to be still be a valid install target the
  first of these would additionally Provides: linux-tools to allow simple
  selection of the appropriate flavour specific package where there is only
  one, or to help the user make an informed choice where there is more.

  The first would be the logical choice when wanting to maintain tools
  installed for all future version of the kernel, mirroring the kernels as
  installed by the linux-<flavour> and linux-image-<flavour> packages and
  keeping the user up to date in tools.  The second would be the appropriate
  package to request installation when trying to target a specific
  kernel version and would be used by the wrapper when requesting manual
  intervention such as when the linux-tools-<flavour> is not installed.

  The first of these would be added to the appropriate meta package, the
  second would come out of the flavour specific packages in the main kernel
  source package.

  Further we would then be able to name the actual binary packages as produced by the 
  various source packages to be source package specific.  Thus we would have packages as
  below:

      linux-tools-<abi>			-- coming out of the master branch
      linux-grouper-tools-<abi>		-- coming out of the grouper branch

  These would be hidden from the user via the previously listed meta packages
  and would not be direct installation candidates.

  There is also an additional linux-tools-common package which represents
  the manual pages and the wrappers.  These would be only generated and
  installed from the master branch and all of the other flavours would
  (at least initially) share this package.

  The actual binaries will be moved over to names similar to below:

      /usr/lib/<srcpkg>-tools-<abi>/<binary>

  with symlinks in as below for each flavour pointing to the above:

      /usr/lib/linux-tools/<binary>-<abi>-<flavour>

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1205284/+subscriptions