Re: Naming scheme of fis-gtm binary packages (Was: Bug#1009900: fis-gtm: Multiple CVEs in fis-gtm)
Hi Amul,
Am Mon, Jul 11, 2022 at 07:51:55PM +0000 schrieb Shah, Amul:
> Hi Andreas,
> We discussed this in the group and a number of people were not comfortable with removing the current versioning scheme. Let me revise my explanation of our versioning:
>
> GT.M’s versioning follows this scheme:
> DBVersion.Major-Minor[Patch]
> - DBVersion corresponds to the database block version
> - Major corresponds to a major feature change in the product
> - Minor represents a minor/incremental feature change in the product
> - Patch is an alphabet denoting an emergency single change release
>
> What do other DB projects do in this case?
The package name will be changed if the database format becomes incompatible.
This corresponds to my suggestions to name the package
DBVersion.Major
(and leave out "-Minor[Patch]"
> Could we make the DB version a textual string and ignore it with respect to the version number?
The point is that the package name should not change that frequently.
If you want to change the textual string than there is no advantage over
the current naming scheme.
> Currently V6.3-014 has a FTBFS #1011722 logged against it. It would be good to get V7.0-003 in the testing stream to close the bug.
Can you tell me exactly what is the problem with simply choosing V7.0
for all V7.0 package releases and switch to V7.1 once this version is
released? If the information about Minor + Patchlevel is relevant
for the user (but not for binary compatibility of the database) it
could be mentioned inside the package description which can be changed
more easily than the package name. To make it clear what I mean I
propose the following patch against the current Git repository:
diff --git a/debian/control b/debian/control
index 15f2d39..fb077fb 100644
--- a/debian/control
+++ b/debian/control
@@ -61,7 +61,7 @@ Description: metapackage for the latest version of FIS-GT.M database
.
This metapackage always depends from the default fis-gtm version.
-Package: fis-gtm-7.0-002
+Package: fis-gtm-7.0
Architecture: amd64 i386
Multi-Arch: same
Depends: ${shlibs:Depends},
@@ -71,7 +71,7 @@ Recommends: zlib1g
Pre-Depends: ${misc:Pre-Depends}
Provides: gtm,
mumps
-Description: package for FIS-GT.M database
+Description: FIS-GT.M database version 7.0-002
GT.M is a database engine with scalability proven in large real-time
transaction processing systems that have thousands of concurrent
users, individual database file sizes to the Terabyte range (with
(I understood that we should rather release -003 but this is not
commited yet.)
I think you realised that every single package change requires passing
the Debian new queue and the time this takes is simply not determined.
Due to that fact and the unfortunate naming scheme we end up with
extremely long cycles (currently with a long standing RC bug due to
several CVEs) which is not in the interest of our users. I keep on
failing t understand why the minor version should be a part of the
package name which I have never seen in any other Debian package.
Kind regards
Andreas.
> Thanks,
> Amul
>
> From: Shah, Amul <Amul.Shah@fisglobal.com>
> Date: Friday, 06 17, 2022 at 04:04 PM
> To: Andreas Tille <andreas@an3as.eu>, Debian Med Project List <debian-med@lists.debian.org>
> Subject: Re: Naming scheme of fis-gtm binary packages (Was: Bug#1009900: fis-gtm: Multiple CVEs in fis-gtm)
> Hi Andreas,
> Thanks for changing the subject and dropping the bug tracker. I realized
> my faux pas after the bug tracker replied to my email.
>
> > > Could you remind me about what we are doing to cause this problem? Is it the installation path?
> > > Or did you mean the below situation where there are two possible GT.M versions?
> > > > aptitude search fis-gtm
> > > p fis-gtm - metapackage for the latest version of FIS-GT.M database
> > > i fis-gtm-6.3-002 - package for FIS-GT.M database
> > > p fis-gtm-6.3-014 - package for FIS-GT.M database
> >
> > We (rather you, Bashkar and Luis Ibanez) decided to create a new binary
> > package name for any mikro fis-gtm release to enable co-installation of
> > all those packages. I'm personally not convinced, that any single minor
> > version bump needs to be installed on a typical Debian installation.
> > This I would rather go with binary package names like fis-gtm-6.3 or
> > fis-gtm-7.0 no matter whether what mikro version "-002" currently - may
> > be "-003" next etc. the package is featuring.
>
> [amul] I think we’re on the same page, to use MAJOR.MINOR in the package name.
> Neither Bhaskar nor Luis Ibanez are working on fis-gtm. Let me discuss this here at
> FIS. I don’t see any reason why we cannot adopt the naming scheme that you
> propose, fis-gtm-Major.Minor, which also matches what other projects use.
>
> > However, I do not know anything about fis-gtm and its compatibility between
> > micro versions - so may be I'm just on the wrong track while looking from
> > a Debian packaging perspective. My perspective is that I'm just scared
> > by uploading to the new queue for every single micro version bump which
> > always is causing unpredictable delays until the package gets accepted in
>
> [amul] GT.M’s versioning follows this scheme:
> Major.Minor-Increment[Patch]
> - Major corresponds to the database block version
> - Minor corresponds to a major feature change in the product
> - Increment (micro) represents a minor feature change in the product
> - Patch is an alphabet denoting an emergency single change release
>
> [amul] GT.M database formats (major version) change infrequently. Inside a
> database version, GT.M is tested in various upgrade<->downgrade scenarios.
> Meaning that there should be no reason to not upgrade.
>
> Thanks,
> Amul
>
>
> From: Andreas Tille <andreas@an3as.eu>
> Date: Friday, 06 17, 2022 at 04:44 AM
> To: Shah, Amul <Amul.Shah@fisglobal.com>, Debian Med Project List <debian-med@lists.debian.org>
> Subject: Naming scheme of fis-gtm binary packages (Was: Bug#1009900: fis-gtm: Multiple CVEs in fis-gtm)
> Hi Amul,
>
> Am Thu, Jun 16, 2022 at 05:58:54PM +0000 schrieb Shah, Amul:
> > > Please reconsider the "add any minor version bump leads to a new binary
> > > file name" strategy. This means that fis-gtm always needs to pass the
> > > Debian new queue which always means that there is a hardly predictable
> > > delay when the package will reach the distribution.
> >
> > Could you remind me about what we are doing to cause this problem? Is it the installation path?
> >
> > Or did you mean the below situation where there are two possible GT.M versions?
> > > aptitude search fis-gtm
> > p fis-gtm - metapackage for the latest version of FIS-GT.M database
> > i fis-gtm-6.3-002 - package for FIS-GT.M database
> > p fis-gtm-6.3-014 - package for FIS-GT.M database
>
> We (rather you, Bashkar and Luis Ibanez) decided to create a new binary
> package name for any mikro fis-gtm release to enable co-installation of
> all those packages. I'm personally not convinced, that any single minor
> version bump needs to be installed on a typical Debian installation.
> This I would rather go with binary package names like fis-gtm-6.3 or
> fis-gtm-7.0 no matter whether what mikro version "-002" currently - may
> be "-003" next etc. the package is featuring.
>
> However, I do not know anything about fis-gtm and its compatibility between
> micro versions - so may be I'm just on the wrong track while looking from
> a Debian packaging perspective. My perspective is that I'm just scared
> by uploading to the new queue for every single micro version bump which
> always is causing unpredictable delays until the package gets accepted in
> unstable.
>
> Kind regards
> Andreas.
>
> --
> https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Ffam-tille.de%2F&data=05%7C01%7Camul.shah%40fisglobal.com%7Ce96ad6345d394b1093ce08da503da2fa%7Ce3ff91d834c84b15a0b418910a6ac575%7C0%7C0%7C637910522906205826%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=G2qz%2FLtIkoQ3TmMKfWU8TBCCYsxsgO8oKFdFRQ5xUhA%3D&reserved=0
>
> FIS Internal Use Only
>
> The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
>
> FIS Internal Use Only
--
http://fam-tille.de
Reply to: