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

ytao yue.tao at windriver.com
Mon Aug 16 03:17:35 UTC 2021

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 
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|| 
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.
> 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>
>> *Sent:* July 26, 2021 3:33 AM
>> *To:* starlingx-discuss at lists.starlingx.io 
>> <starlingx-discuss at lists.starlingx.io>; Asselstine, Mark 
>> <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/20210816/f0b62161/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stx_deb_folder_layout.rst
Type: text/x-rst
Size: 9452 bytes
Desc: not available
URL: <http://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20210816/f0b62161/attachment-0001.bin>

More information about the Starlingx-discuss mailing list