Re: Debian12 repository.

[Andreas Fink]

On 20 Nov 2023, at 15:39, Riccardo Mottola <riccardo.mottola@libero.it> wrote:
> 
> Hi,
> 
> Andreas Fink wrote:
>> As far as renaming goes, well the packages in debian are so far outdated and 
>> seem no longer maintained that we should try to get a newer version into 
>> debian at some point.  But im not sure on how that process works . It might 
>> fail due to non support of gcc and maybe some platforms (such as RiscV 
>> because even clang fails to install currently).
>> 
> 
> this is not correct. If you check the current debian unstable packages, they 
> are quite up-to-date.
> 
> https://packages.debian.org/search?keywords=gnustep&searchon=names&suite=unstable&section=all
> 
> Gives us:
> 
> 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?

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.

So if its compiled with gcc with the old runtime, we are in dead water for the 
future. clang is the only way for modern Objective-C which I think is mandatory 
to attract any decent Objc-developers to even consider GNUStep. One of the key 
targets of GNUStep is to be feature compatible (where possible) with MaOS which 
makes it a prime candidate for porting apps from MacOS to Linux and other Unix 
platforms. Without support for ARC, the vast majority of code written in the 
past 15 years will not work (or eat memory without ever freeing it up). Apple's 
reference guide to Objective C 2.0 which introduces ARC is from 2008!

In my eyes, the best would be to have ARC versions in a repo which are built 
with clang and will end up in debian stable at some time.
or have two version. gnustep and gnustep-legacy (non ARC). But I think it would 
not be compatible somehow to have both installed.

We can not avoid that we have to do a transition to clang.

So lets stick our heads together and decide on how we can make this as smooth 
as possible.

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?