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


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

      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.


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
dl_path:
  name: dtc-1.4.4.tar.gz
  url: https://www.kernel.org/pub/software/utils/dtc/dtc-1.4.4.tar.gz
  md5sum: e558cd0e244f122bcb4ebaca166aea4e
revision:
  dist: $STX_DIST
  PKG_GITREVCOUNT:

==================


More details please see the stx_deb_folder_layout.rst file.


Thanks,

ytao



  • **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 and the script that parses it. I will do assessment for debian/watch.


Thanks,

ytao


If you have any questions please let me know.

Regards
chuck






From: ytao <yue.tao@windriver.com>
Sent: July 26, 2021 3:33 AM
To: starlingx-discuss@lists.starlingx.io <starlingx-discuss@lists.starlingx.io>; Asselstine, Mark <Mark.Asselstine@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
https://docs.starlingx.io/specs/specs/stx-6.0/approved/starlingx_2008704_debian_transition.html

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:

https://opendev.org/starlingx/integ/src/branch/master/base/dhcp/centos

We will create a debian folder in same location

https://opendev.org/starlingx/integ/src/branch/master/base/dhcp/debian.

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.


Thanks,

ytao