Re: Naming scheme of fis-gtm binary packages (Was: Bug#1009900: fis-gtm: Multiple CVEs in fis-gtm)
Hi again,
I wonder if there is some decision about the naming scheme. I *really*
want to get the CVE bugs fixed. Users might consider Debian packages
useless otherwise.
Kind regards
Andreas.
Am Tue, Jul 12, 2022 at 07:44:13AM +0200 schrieb Andreas Tille:
> 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
>
>
--
http://fam-tille.de
Reply to: