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 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.
