Re: gnustep2 package

[Tom Sheffler]

I like the gnustep2 package name.
clang+ARC is the right direction, IMO.

Tom


> On Nov 24, 2023, at 4:39 AM, discuss-gnustep-request@gnu.org wrote:
> 
> Send Discuss-gnustep mailing list submissions to
>       discuss-gnustep@gnu.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>       https://lists.gnu.org/mailman/listinfo/discuss-gnustep
> or, via email, send a message with subject or body 'help' to
>       discuss-gnustep-request@gnu.org
> 
> You can reach the person managing the list at
>       discuss-gnustep-owner@gnu.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Discuss-gnustep digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: Debian12 repository. (Andreas Fink)
>   2. Re: Debian12 repository. (H. Nikolaus Schaller)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Fri, 24 Nov 2023 13:11:00 +0100
> From: Andreas Fink <afink@list.fink.org>
> To: "H. Nikolaus Schaller" <hns@goldelico.com>
> Cc: Riccardo Mottola <riccardo.mottola@libero.it>, Hugo Melder
>       <admin@hugomelder.com>, discuss-gnustep@gnu.org
> Subject: Re: Debian12 repository.
> Message-ID: <583F0659-3AD8-4D84-86CC-4E3DD3084B28@list.fink.org>
> Content-Type: text/plain; charset="utf-8"
> 
> 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 <hns@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
>> 
>> 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 <afink@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.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
>>> 
>>> 
>>> 
>> 
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> <https://lists.gnu.org/archive/html/discuss-gnustep/attachments/20231124/922fd45c/attachment.htm>
> 
> ------------------------------
> 
> Message: 2
> Date: Fri, 24 Nov 2023 13:39:30 +0100
> From: "H. Nikolaus Schaller" <hns@goldelico.com>
> To: Andreas Fink <afink@list.fink.org>
> Cc: Riccardo Mottola <riccardo.mottola@libero.it>, Hugo Melder
>       <admin@hugomelder.com>, discuss-gnustep@gnu.org
> Subject: Re: Debian12 repository.
> Message-ID: <1B323C1F-F8C7-468D-9AE9-65514FBBED57@goldelico.com>
> Content-Type: text/plain; charset="utf-8"
> 
> 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 <afink@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 <hns@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 <afink@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.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
>>>> 
>>>> 
>>>> 
>>> 
>> 
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> <https://lists.gnu.org/archive/html/discuss-gnustep/attachments/20231124/03e87f8e/attachment.htm>
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep
> 
> 
> ------------------------------
> 
> End of Discuss-gnustep Digest, Vol 252, Issue 7
> ***********************************************