[Starlingx-discuss] [Debian Build]: Layout of the debian folder

Short, Charles Charles.Short at windriver.com
Mon Aug 16 12:44:37 UTC 2021


Comments in line

From: Tao, Yue <Yue.Tao at windriver.com>
Sent: Sunday, August 15, 2021 11:18 PM
To: Short, Charles <Charles.Short at windriver.com>; starlingx-discuss at lists.starlingx.io; Asselstine, Mark <Mark.Asselstine at windriver.com>; Bai, Haiqing <Haiqing.Bai at windriver.com>; Panech, Davlet <Davlet.Panech at windriver.com>
Subject: Re: [Starlingx-discuss] [Debian Build]: Layout of the debian folder

On 7/27/21 10:52 AM, ytao wrote:

On 7/27/21 7:05 AM, Short, Charles wrote:

      First of all, I'm appreciated for your input.

I had a look through the document and it looks okay. I just have a couple of comments/questions about the folder content:

  *   **debver** - This is the package version of the debian package? This is generated from the debian/changelog when the package is built. I guess the problem is that you want to differentiate from a starlingx package and native package? My suggestion would be what the Ubuntu developers do. For example, if we have patches to apply for systemd, the debian version would be 247.3-3, while the StarlingX package would be 247.3-3stx0. Then a user or developer can quickly see that they are working with a native debian package or a starlingx modified package.

       For a Debian native package, the *debver* is the debian version. We use it to download the src via "apt-source packagname=debver", for a starlingx package, it is up to the developer. I observed in CentOS version, they added a patch to change the package version, for example integ/base/lighttpd/centos/meta_patches/Update-package-versioning-for-TIS-format.patch, which appends a 'tis' to package version, that requests developer to update the version manually. After transiting to debian, OBS can achieve it automatically. It can append 'tis' or 'stx' to a package, so don't need developers to update it manually.

Recently, we found an issue related to "--append-to-version" option of sbuild, via which we append the ".stx" to a built package version, so that we don't need to involve a developer to modify revision manually. A upstream commit https://salsa.debian.org/debian/sbuild/commit/9741ec6eb018d500a93e607f998dda8af52c9ce0 forces the "--append-to-version"implies "--no-arch-all", which causes the packages with --arch-all are skipped by sbuild, for example, most of the python modules, so we have to give up the "--append-to-version" option.

Yeah I don’t think we should be using sbuild in this manner. To change the version of the package you should be using the “dch” command. Sbuild is akin to mock for fedora, and it should be really only used for building packages.

After reviewing the function "srpm_source_build_data()" in https://opendev.org/starlingx/root/src/branch/master/build-tools/srpm-utils in depth, we decide to inherit the PKG_GITREVCOUNT/SRC_GITREVCOUNT/

PKG_BASE_SRCREV/SRC_BASE_SRCREV 4 macros from CentOS version to increase the revision automatically. Difference with CentOS version is using a yaml file instead of build_srpm.data.  And we define a new environment variable $STX_DIST (default value is ".stx"), which is appended to built package version.

A new yaml file is involved, why not to merge other files into the yaml file? Hence, we merge the dl_path/src_path/debver/debname into meta_data.yaml, a sample of the meta_data_yaml

$cat integ/base/libfdt/debian/meta_data.yaml


debver: 1.4.4-1
debname: libfdt
  name: dtc-1.4.4.tar.gz
  url: https://www.kernel.org/pub/software/utils/dtc/dtc-1.4.4.tar.gz
  md5sum: e558cd0e244f122bcb4ebaca166aea4e
  dist: $STX_DIST


More details please see the stx_deb_folder_layout.rst file.



  *   **deb_patches** - As a developer, if the package has its debian/patches I would rather use the debian/patches directory. If the directory doesnt exist I am more likely to create a debian/patches directory and then send a patch to debian to fix a problem.

       Exactly, we should send a fix to debian community and then uprev the package to get the fix, but we also need to consider local changes. The *patches" folder contains the local change for source codes, that will be copied to debian/patches (or create it if doesn't exist), and update the debian/patches/series. The *deb_patches* contains the patches to change debian folder, for example, we want to customize the installation of a package, we need to update override_dh_install stage in debian/rules. The patches will be applied to package/debian folder directly.

       The *deb_patches* is similar with centos/meta_patches

       The *patches* is similar with centos/patches

  *   **dl_path** - Debian already does this for you already, the debian/watch file keeps track of where to download a tarball, or a zip file, or a python wheel for you. You can use uscan(1), which is a part of devscripts package. Debian/Ubuntu developers have been doing this for years. (https://wiki.debian.org/debian/watch)

         Thanks you for pointing me the debian/watch. I will take some time to learn about debian/watch and go back soon. It looks a debian file for monitoring the upstream version change. I am not sure if it is suitable for a no debian package. In our internal discussion, Davlet told me a special case, that the url of a tar ball likes this https://api.github.com/repos/ceph/jerasure/tarball/96c76b89d661c163f65a014b8042c9354ccf7f31

          As Davlet's suggestion, the *dl_path* refers to example file<https://opendev.org/starlingx/integ/src/branch/master/centos_tarball-dl.lst> and the script that parses it<https://opendev.org/starlingx/tools/src/branch/master/centos-mirror-tools/dl_tarball.sh#L215>. I will do assessment for debian/watch.



If you have any questions please let me know.

debian/watch - Debian Wiki<https://wiki.debian.org/debian/watch>
debian/watch. The file named watch in the debian directory is used to check for newer versions of upstream software is available and to download it if necessary. The download itself will be performed with the uscan program from the devscripts package. It takes the path to the debian directory that uses the watch file as an argument or searches the directories underneath the current working ...

From: ytao <yue.tao at windriver.com><mailto:yue.tao at windriver.com>
Sent: July 26, 2021 3:33 AM
To: starlingx-discuss at lists.starlingx.io<mailto:starlingx-discuss at lists.starlingx.io> <starlingx-discuss at lists.starlingx.io><mailto:starlingx-discuss at lists.starlingx.io>; Asselstine, Mark <Mark.Asselstine at windriver.com><mailto:Mark.Asselstine at windriver.com>
Subject: [Starlingx-discuss] [Debian Build]: Layout of the debian folder

Hello Everyone:

You may have known Wind River team is working on the transition to
Debian OS, more details of the project can be found at
https://docs.starlingx.io/specs/specs/stx-6.0/. My purpose is launching
a discussion about the userspace packages transition to Debian. The spec
can be found at

In order to inherit the existing userspace construction as much as
possible, our proposal is creating a 'debian' folder in same directory
with 'centos' folder for each package. For example, the dhcp package in
integ repo, it's centos folder is at:


We will create a debian folder in same location


All materials in this folder control building dhcp under Debian host.
The "stx_deb_folder_layout.rst" is the layout of debian folder. I also
attach a couple of samples to demonstrate how to fill the debian folder
for a debian package and a 3rd package.

This layout is not the final version, I'm appreciated for any suggestion
from you.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20210816/17451612/attachment-0001.html>

More information about the Starlingx-discuss mailing list