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

ytao yue.tao at windriver.com
Tue Aug 17 01:32:27 UTC 2021

On 8/16/21 8:44 PM, Short, Charles wrote:
> Hi,
> 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:
>         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.
> 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.
Yeah, new method is using "dch" command to update changelog by parsing 
the "revision" of meta_data.yaml.


> 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
> ==================
> 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
>     <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.
>     Thanks,
>     ytao
>         If you have any questions please let me know.
>         Regards
>         chuck
>         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 ...
>         wiki.debian.org
>         ------------------------------------------------------------------------
>         *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
>         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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20210817/d82cf5d4/attachment-0001.html>

More information about the Starlingx-discuss mailing list