Re: Request to add tss to security packages
Hello Debora,
> Hello. Apologies for my absense on this, I had some personal life
> changing event at the end of last year but am now able to focus on this
> project again.
No worries, my availability also becomes spotty from time to time.
> > The deprecation of the tss2 package might require some extra steps,
> > but nothing too complicated, on a high level:
> > 1) Introduce the new package "ibmtss", with a "Breaks/Replaces" set
> > to
> > specific versions of tss2.
> > 2) Transform the tss2 package into a transitional dummy package
> > (empty
> > package that depends on ibmtss).
> I did attempt to do that in debian/control. But this is the first
> pacakge I have worked on so I very much appreciate a review.
Great, the packaging is looking good, but there are some things that should be
changed to simplify and follow our most up-to-date procedures. If you
distribute this package internally at IBM, you can also consider doing these
changes there.
For ease of reference, I will enumerate each suggestion and they won't follow
any special ordering. Feel free to ask me for more details if needed.
1) git repo layout and contents:
We recommend following the DEP14 guidelines for the git layout of the
packaging: https://dep-team.pages.debian.net/deps/dep14/
Effectively, for this package, this means:
1.1) The main branch should be "debian/unstable", some people prefer
"debian/latest" but that will cause clashes with experimental changes, if we
ever push those. This branch should also contain the upstream code together
with the "debian/" folder with the packaging.
1.2) There should be a "pristine-tar" branch, automatically generated and maintained by gbp.
1.3) There should be an "upstream" or "upstream/latest" branch with the
upstream code, automatically generated and maintained by gbp, without the
debian/folder.
There are multiple ways this can be solved, but the simplest one is by
re-creating the git repo, with a side-effect of losing the history. If that's
an issue, let me know, but I noticed there aren't a lot of commits so I'm
assuming that will be fine, here's how you would do it:
* Build the package, making sure there's a resulting .dsc file.
* Run "gbp import-dsc --pristine-tar --debian-branch=debian/unstable path-to-dsc.dsc".
This command should create a brand new git repo, assuming you run it from
outside one (and there isn't an existing git repo at cwd).
I haven't performed these steps myself for this package to double-check, so in
case I forgot any parameter or requirement and you get an error, let me know.
2) d/watch: Missing contents:
The "debian/watch" file should be set up so that our tools are able to identify
new releases: https://wiki.debian.org/debian/watch. Sometimes this is not
possible, but it should work just fine for SourceForge.
We should also bump it to v4.
3) debhelper: compat 13:
The latest version of debhelper we use if 13, in order to use that you'll have to:
* Replace "debhelper (>= 10)" with "debhelper-compat (= 13)" under "Build-Depends" on d/control.
* Remove the "debian/compat" file, that is not needed anymore.
4) d/include-binaries:
This might be an issue for inclusion of the package, at least if it's for the
"main" component (and not non-free).
Can you clarify what those binaries are, if their sources are available, and if
they are needed? I'll describe a simplification of the approaches in case of
yes/no:
If they are not needed, we can drop them from the source with a repack, using
the "Files-Excluded" field in d/copyright:
https://wiki.debian.org/UscanEnhancements#Deleting_Files_using_Files-Excluded_field_in_debian.2Fcopyright
If they are needed, we need to check if it's possible to generate them at build
time, and/or where is the source code of that.
In case they are needed and there are no sources, then this package has to go
instead to the "non-free" section.
5) d/*.dirs and d/*.install files:
I have not built this package yet, as I'll wait for the other issues to be
solved first, so I'm not certain about this item. I'm mentioning it anyway as
you might want to check the below.
Depending on how the upstream project is setup, these should not be needed. So
a few things could be happening here:
* We don't need the files as debhelper is able to do the right thing given the
upstream's makefile.
* We need to set them but there's an alternative makefile/build method provided
by upstream which would remove this need.
* We need to set them and upstream has no makefile/build method which does that
by default. In this case, there's a possibility to make this change directly
upstream, but that is not a requirement (FTR: this issue would also affect
other distros' packaging).
6) Transitional package tss2:
I'm afraid the transition will be slightly more complicated than this due to
the versioning and SONAME changes.
The old package, tss2, has version 1045-2.1.
The new one, ibmtss, has version 2.1.1-1.
This means there are certain transition approaches we can't take as the new
package has a lower version compared to the old one.
For now, you can remove the transitional package in d/control and keep the
Breaks/Replaces set.
I'll have to think about the best approach to solve this and we can come back
to it later.
7) d/patches/do-not-run-tests.patch: DEP-3 headers:
The patch is missing the DEP-3 headers:
https://dep-team.pages.debian.net/deps/dep3/.
The important fields to have in this case are "Description", "Author" and
"Forwarded".
7) What I didn't review:
I did not want to review everything at once due to the amount of work required,
I would rather we deal with the listed issues first.
The things that I left behind would not be big issues anyway, but here's some:
* I'm not sure everything under d/rules is needed, especially the override on
dh_compress (they might be there as a workaround of another issue).
* The .pem and .crt files shipped: I would like to understand what they are
used for.
* The transition method, which I described in number 6.
Thank you for contributing!
--
Samuel Henrique <samueloph>
Reply to: