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.s...@fisglobal.com>
> > Date: Friday, 06 17, 2022 at 04:04 PM
> > To: Andreas Tille <andr...@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 <andr...@an3as.eu>
> > Date: Friday, 06 17, 2022 at 04:44 AM
> > To: Shah, Amul <amul.s...@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
