| 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
gnustep2 sounds logical as its a logical upgrade path from old non arc.
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
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. 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).
The question now is what naming to choose gnustep2...? gnustep-arc..? gnustep-clang-... ? On 24 Nov 2023, at 11:04, Riccardo Mottola <riccardo.mottola@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
|