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 <[email protected]>:
>
> 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
>>
>> <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
>>>
>>>
>>>
>>
>
