gnustep2 sounds logical as its a logical upgrade path from old non arc.
I have built it that way now on repo.gnustep.ch <http://repo.gnustep.ch/> debian12 on intel and arm64 armhf (raspberry pi), ubuntu22 (intel, arm64) will follow i also have built a metapackage named "gnustep2" if you install this, you basically get base, gui, back, corebase, libobjc2, libdispatch, libiconv > On 24 Nov 2023, at 12:42, H. Nikolaus Schaller <[email protected]> wrote: > > 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 <[email protected]>: >> >> The question now is what naming to choose >> >> gnustep2...? >> gnustep-arc..? >> gnustep-clang-... ? >> >> >> >>> On 24 Nov 2023, at 11:04, Riccardo Mottola <[email protected]> >>> 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 >> >> >> >
