Hi,
You can specify the version you wish to download, I did the following:
-
apt-get source isc-dhcp
-
cd isc-dhcp-4.4.1
-
uscan –download-version 4.3.5
-
Regards
chuck
From: Tao, Yue <Yue.Tao@windriver.com>
Sent: Friday, July 30, 2021 6:50 AM
To: Tao, Yue <Yue.Tao@windriver.com>; Short, Charles <Charles.Short@windriver.com>; starlingx-discuss@lists.starlingx.io; Asselstine, Mark <Mark.Asselstine@windriver.com>; Bai, Haiqing <Haiqing.Bai@windriver.com>; Panech, Davlet <Davlet.Panech@windriver.com>
Subject: RE: [Starlingx-discuss] [Debian Build]: Layout of the debian folder
Hi Charles:
I did some investigation of debian/watch file, which is the input file for uscan command. It’s purpose is to detect if upstream has a newer release. I tried the uscan, which is limited to run with a full debian
folder, not only a dedbian/watch. I also try to the option “—watchfile” to specify a watch file, but it still checks the debian/changelog file.
$uscan –watchfile path/watch
uscan die: Are you in the source code tree?
Cannot find readable debian/changelog anywhere! at
And the url in watch file must be a regex expression, for example,
Allow
http://ftp.isc.org/isc/dhcp/(\d.\d.\d*)/dhcp-(\d.*)\.(?:tgz|tbz2|txz|tar\.(?:gz|bz2|xz))
Not allow
http://ftp.isc.org/isc/dhcp/4.4.2/dhcp-4.4.2.tar.gz
A developer only care about a special version, but he has to build a regex expression, of cause uscan has –download-version to specify a version, but watch file can’t meet a unregular url, like
https://api.github.com/repos/ceph/jerasure/tarball/96c76b89d661c163f65a014b8042c9354ccf7f31, which is a downloading url in Starlingx repositories.
I think it’s better not to use the uscan+watch to download 3rd part packages.
Thanks,
ytao
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.
-
**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.
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 ...
|