File: control.in

package info (click to toggle)
brewtarget 4.2.1-1
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid
  • size: 35,468 kB
  • sloc: cpp: 56,958; xml: 19,031; python: 1,266; sh: 183; makefile: 11
file content (186 lines) | stat: -rw-r--r-- 10,592 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
#
# packaging/linux/control.in is part of Brewtarget, and is copyright the following authors 2023-2024:
#   • Matt Young <mfsy@yahoo.com>
#
# Brewtarget is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later
# version.
#
# Brewtarget is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied
# warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for more
# details.
#
# You should have received a copy of the GNU General Public License along with this program.  If not, see
# <http://www.gnu.org/licenses/>.
#

#
# See comments in meson.build for how this file gets processed into mbuild/control.  Then see comments in the build tool
# script (bt) for how we strip out comments, join "folded" lines and output to
# mbuild/packaging/linux/[projectName]-[versionNumber]_amd64/DEBIAN/control.
#
# See https://www.debian.org/doc/debian-policy/ch-controlfields.html the format of a Debian package control file
#
# NB: The lack of blank lines below is deliberate!   A control file consists of one or more "stanzas" of fields.  The
# stanzas are separated by empty lines.  Some control files allow only one stanza; others allow several (eg one for a
# source package and another for the binary packages generated from that source).  To keep things simple, we only ship
# the binaries in the deb package, because the source code is easily available by other routes.  So we only want one
# stanza.  So, no blank lines.  (I'm very much hoping that comments are OK inside a stanza.)
#
# See https://www.debian.org/doc/debian-policy/ch-controlfields.html#binary-package-control-files-debian-control for the
# fields in the stanza of a binary package control file.
#
#
# Package (Mandatory) : name of the binary package
#    Package names (both source and binary) must consist only of lower case letters (a-z), digits (0-9), plus (+) and
#    minus (-) signs, and periods (.). They must be at least two characters long and must start with an alphanumeric
#    character.
#
Package: @CONFIG_APPLICATION_NAME_LC@
#
# Source (Optional) : source package name
#    We don't specify this as we don't ship the source as a deb package
#
# Version (Mandatory) : version number of a package. The format is: [epoch:]upstream_version[-debian_revision].
#
Version: @CONFIG_VERSION_STRING@-1
#
# Section (Recommended) : application area into which the package has been classified
#    See https://packages.debian.org/unstable/ for a list of all the sections.  TLDR is that misc is the closest fit for
#    us.
#
Section: misc
#
# Priority (Recommended) : Represents how important it is that the user have the package installed
#    Since not all Linux users brew beer, optional seems pretty reasonable here, especially as it is "the default
#    priority for the majority of the [Debian] archive"
#
Priority: optional
#
# Architecture (Mandatory) : in this context it's "a unique single word identifying a Debian machine architecture"
#    Fortunately we don't have to worry about catering to every possibility (which you can see eg by running
#    `dpkg-architecture -L` on the command line on Ubuntu.
#
Architecture: amd64
#
# Essential (Optional) : We don't need this.  It's only for packages that aren't supposed to be removeable
#
# Depends, Recommends, Suggests, Enhances, Pre-Depends : Dependencies on, conflicts with, other packages
#    If we were doing everything the true Debian way, including shipping a source package and its makefile (yikes!) then
#    there are various tools such as `dh_makeshlibs` and `dh_shlibdeps` that help us generate the right dependencies.
#    All we would have to put here is 'Depends: ${shlibs:Depends}' or some such.  However, if we only want to ship a
#    binary and not maintain a separate build with its own makefile for the source code, then those tools won't help and
#    we need to maintain things manually here.  Fortunately our list of dependencies is not horrendous.
#
#    We can get an initial list of shared libraries that a binary depends on in a number of ways (per
#    https://stackoverflow.com/questions/6242761/determine-direct-shared-object-dependencies-of-a-linux-binary), but the
#    following gives quite neat output:
#
#       objdump -x myExecutable | grep NEEDED | sort
#
#    For our binary, this (as of 2024-10-22) gives
#       NEEDED               ld-linux-x86-64.so.2
#       NEEDED               libc.so.6
#       NEEDED               libgcc_s.so.1
#       NEEDED               libm.so.6
#       NEEDED               libQt6Core.so.6
#       NEEDED               libQt6Gui.so.6
#       NEEDED               libQt6Multimedia.so.6
#       NEEDED               libQt6Network.so.6
#       NEEDED               libQt6PrintSupport.so.6
#       NEEDED               libQt6Sql.so.6
#       NEEDED               libQt6Widgets.so.6
#       NEEDED               libstdc++.so.6
#       NEEDED               libxalan-c.so.112
#       NEEDED               libxerces-c-3.2.so
#
#    We then need to find which packages provide these shared libraries.  Assuming we're on a system where all the
#    dependencies are already installed (eg the one where we've just build the software), we can do this with dpkg, eg
#    running `dpkg -S libQt6Core.so.6` gives:
#
#       libqt6core6t64:amd64: /usr/lib/x86_64-linux-gnu/libQt6Core.so.6.4.2
#       libqt6core6t64:amd64: /usr/lib/x86_64-linux-gnu/libQt6Core.so.6
#
#    So, eg, for an executable called "brewken" we can put this all together into:
#       objdump -x brewken | grep NEEDED | awk '{print $2}' | xargs dpgg -S | grep ^lib | awk -F: '{print $1}' | sort -u
#
#    Note that you can see the version of a package libfoobar by running the following command from the shell:
#       apt-cache show foobar | grep Version
#
#    And we can combine this altogether in the following (linebreaks added for readability):
#       objdump -x brewtarget | grep NEEDED | awk '{print $2}' | xargs dpkg -S | grep ^lib | awk -F: '{print $1}' |
#          sort -u | while read ii
#          do
#             echo -e $ii '\t' $(apt-cache show $ii | grep Version | head -1 | sed 's/Version: //; s/ubuntu[^ ]*//; s/[^0-9\.].*//')
#          done | sort
#    which gives us nearly the output we want.
#
#    The only remaining issue is that showing the currently-installed versions of packages on the build machine doesn't
#    give us the _minimum_ required versions, so we may end up specifying more recent versions of things than are
#    strictly required.  Usually we can check for problems here by looking what the most recent available version of a
#    package is for the oldest version of Ubuntu we support (via https://packages.ubuntu.com/ - though NB you sometimes
#    have to knock the t64 off the end of the name to find a match).
#
#    Normally, this field is (surprisingly) not allowed to be "folded" (ie split across multiple lines).  However, we do
#    our own folding in the bt build script, so the backslash line continuations are OK here!
#
#    Note that some libraries have a "t64" version which is used instead of the "base" one (eg libqt6network6t64 instead
#    of libqt6network6).  This is to do with upgrades to 64-bit time (to fix the "year 2038 problem") -- per
#    https://wiki.debian.org/ReleaseGoals/64bit-time.  For the moment, we specify both the "t64" and "non-t64" versions
#    to allow things to work on Ubuntu (mostly already migrated to t64) and Debian Stable (mostly not yet migrated to
#    t64).
#
#    Note too that qt6-translations-l10n is not required in terms of providing any functions that we call, but it does
#    ensure the Qt framework's own translation files are installed.
#
#    Now that we are on Qt6, we need to explicitly specify as a libqt6svg6 dependency, otherwise .svg files (which we
#    use a lot in icons) will not display (see
#    https://stackoverflow.com/questions/76047551/icons-shown-in-qt5-not-showing-in-qt6)
#
Depends: \
   libc6        (>= 2.35  ), \
   libc6-dev    (>= 2.35  ), \
   libc6-i386   (>= 2.35  ), \
   lib32gcc-s1  (>= 12.2.0), \
   lib32stdc++6 (>= 12.2.0), \
   libgcc-s1    (>= 12.2.0), \
   libstdc++6   (>= 12.2.0), \
   libqt6core6         | libqt6core6t64         (>= 6.2.4 ), \
   libqt6gui6          | libqt6gui6t64          (>= 6.2.4 ), \
   libqt6multimedia6                            (>= 6.2.4 ), \
   libqt6network6      | libqt6network6t64      (>= 6.2.4 ), \
   libqt6printsupport6 | libqt6printsupport6t64 (>= 6.2.4 ), \
   libqt6sql6          | libqt6sql6t64          (>= 6.2.4 ), \
   libqt6svg6                                   (>= 6.2.4 ), \
   libqt6widgets6      | libqt6widgets6t64      (>= 6.2.4 ), \
   libxalan-c112       | libxalan-c112t64       (>= 1.12  ), \
   libxerces-c3.2      | libxerces-c3.2t64      (>= 3.2.3 ), \
   qt6-translations-l10n                        (>= 6.2.4 )
#
# Installed-Size (Optional) : an estimate of the total amount of disk space required to install the named package
#    The disk space is given as the integer value of the estimated installed size in bytes, divided by 1024 and rounded
#    up.  .:TODO:. At some point we should implement this, ideally by having the build system calculate the value
#
#Installed-Size: 17758
#
# Maintainer (Mandatory) : The package maintainer’s name and email address.
#    The name must come first, then the email address inside angle brackets <> (in RFC822 format).  If the maintainer’s
#    name contains a full stop then the whole field will not work directly as an email address due to a misfeature in
#    the syntax specified in RFC822; a program using this field as an address must check for this and correct the
#    problem if necessary (for example by putting the name in round brackets and moving it to the end, and bringing the
#    email address forward).
#
Maintainer: @CONFIG_PACKAGE_MAINTAINER@
#
# Description (Mandatory) : a description of the binary package, consisting of two parts, the synopsis or the short
# description, and the long description
#
Description: GUI beer brewing software
 @CONFIG_APPLICATION_NAME_UC@ is a calculator for brewing beer. It is a Qt-based program which
 allows you to create recipes from a database of ingredients. It calculates
 all the important parameters, helps you with mash temperatures, and just
 makes the process of recipe formulation much easier.
#
# Homepage (Optional)
#
Homepage: @CONFIG_WEBSITE_URL@