Great! a) what is the entry for /etc/apt/sources.list?
The I can test a little b) a next logical step would be to add meta-packages for - gap-minimal depending on gnustep2 package + subpackages for each GAP application - gap full (some more less essential packages) depending on gap-minimal - gsde depdendent on gap-minimal and some X11 setup and other libs and apps (e.g. window manager) Then it becomes really user-friendly to install a full GNUstep desktop... BR, Nikolaus > Am 24.11.2023 um 13:11 schrieb Andreas Fink <af...@list.fink.org>: > > 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 <h...@goldelico.com> 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 >> >> <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 >>> >>> >>> >> >