It seems as if API incompatiblities in libraries are usually denoted by a numerical suffix.
E.g. libfi6, libffi7, libffi8 But there is also libjpeg62-turbo. Here are some hints. https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_debian_package_file_names So although it is clear that it must differ in "package" name, I would say it is a little arbitrary. But is a decision carved in stone for quite some time. Personally I would vote for gnustep2 (alluding to libobjc2). > Am 24.11.2023 um 11:23 schrieb Andreas Fink <af...@list.fink.org>: > > The question now is what naming to choose > > gnustep2...? > gnustep-arc..? > gnustep-clang-... ? > > > >> On 24 Nov 2023, at 11:04, Riccardo Mottola <riccardo.mott...@libero.it> >> wrote: >> >> Hi, >> >> let me try to explain a little the compatibility issue. I am not debating if >> GCC is better or worse, but you want to provide an repository (would be >> "overlay" in gentoo terms) to Debian or Ubuntu, which provides differently >> configured packages. Runtime (in short, let's say ARC here) is the major >> difference, but it could also be layout, root directory, etc. >> The issue is that debian and ubuntu already provide GS packages which are >> configured differently from "yours" and you cannot control how Debian names >> its packages, only "your". >> >> I would configure these package e.g. with --with-layout=gnustep --prefix=/ >> >> This compatibility will remain even if in the future things will change. GCC >> my acquire ARC and libobcj2, it will still be an issue for other things. >> Debian might switch to clang, but you still have a different layout... >> >> Also the amount of packages offered by you might differ. I suppose they >> easily can be "more" because you could provide anything GNUstep has, but you >> might choose not. >> >> You cannot control how debian names their packages right now you can't just >> call them legacy. >> >> Andreas Fink wrote: >>> >>>> base: 1.29 >>>> gui: 0.30 >>>> back: 0.30 >>>> >>>> Randomly checking some other apps shows they are op to release >>>> (ProjectCenter, gorm, GNUMail) >>> Does that version support ARC? >> >> It is irrelevant, those versions are current versions, that is what I wanted >> to show. It depends on how they are compiled and they are compiled with gcc, >> so without ARC. >> For all users which are not developers, they will not care, they install an >> application and it works. Most applications we have do not require ARC. >> Those who notice are mostly developers now. Or in the future more apps will >> be ARC-only, who nows. >> >>> As far as I remember gcc simply doesn't support it. Sticking around with >>> gcc is a dead end. It looks to me like gcc never will ever support >>> objective-2.0 fully. >>> I never even considered the debian packages because ARC does not work with >>> them and thats kind of mandatory now. >> >> While it is up for debate if GCC is a dead-end or not, it was not my point. >> You need to consider debian packages, since they exist and are in the >> official repositories. >> While the libobjc2 runtime is "runtime" compatible with non-ARC code, it is >> (no longer is?) binary compatible with it. So you have to cover e.g. these >> two scenarios: >> >> Debian repo first: >> 1) debian user installs some GNUstep user packages. E.g GWorkspace, Terminal >> and PRICE. They pull in of course gnustep core libraries >> 2) user wants to develop, installs ProjectCenter&GORM, dev packages, ecc >> 3) user needs ARC, adds your repository >> 4) user needs to replace existing packages with "your" packages. All of >> them! Even if they have the same "version" number they need to be mutually >> exclusive >> 5) if a package is not provided by your package it needs to be removed. E.g. >> you provide core, ProjectCenter and GWorkspace, but not Terminal and PRICE. >> They need to me deleted because of unavailable dependency >> >> GS repo first (happy flow) >> 1) debian user does not have any GS app or library installed >> 2) User adds your GS repos, install what it needs, e.g. Core, ProjectCenter >> and GWorkspace >> 3) user attempts to add Terminal and PRICE which you do not provide, he >> needs to fail to install the debian provided versions >> >>> What incompatibilities do we end up having if we use the new runtime 2.0 >>> only? >>> non ARC written code can still be executed. What other clashes will we face? >> >> To my knowledge and experience, in most code I am involved in there is no >> end-user difference. I have two workstations, they run the "same" software >> (all gnustep core tool & apps, all GAP apps + PRICE and some custom apps >> none of which needs objc2) one on linux with GCC and one with FreeBSD and >> clang/libobjc2 and they all compile and run the same. Provided you are on a >> fully supported arch/OS combination, no issues. >> >> Sure there are differences when you debug, compile and things. There may be >> bugs, e.g. do that on NetBSD and with libobjc2 your exceptions won't work. >> >> I wanted to stress the "package tree" incompatibility issue, where mixing is >> impossible for many reasons, not just compiler and runtime. >> >> Riccardo > > >
