Re: Debian12 repository.

[Richard Frith-Macdonald]

> On 24 Nov 2023, at 13:14, Andreas Fink  wrote:
> 
> see http://repo.gnustep.ch/
> 
> I am currently fighting with /usr/GNUstep/System/Tools/gnustep-config while 
> compiling my own libraries
> 
> After changing the layout to gnustep
> 
> the tool is not found in the path. a symlink to /usr/bin/gnustep-config fixes 
> this (or expanding the path)
> However  gnustep-config  --objc-flags  does not include  a 
> -I/usr/include/GNUStep  so  is not found
> 
> It's not strictly necessary for pure objc code but for gnustep-base code it 
> is. There is however no --base-flags but only --base-libs.
> 
> I could simply add -I /usr/include/GNUStep   to my Makefiles. But then why 
> have a config tool when it only does half of the work.
> 
> Suggestions?

> the tool is not found in the path

That means your path is wrong ... but that's easy to fix.

> But then why have a config tool when it only does half of the work.

The problem is not that the tool is doing 'half the work',  it's that your 
headers etc are in the wrong place because you misunderstood what this means:

> After changing the layout to gnustep

If your layout is 'gnustep' the resources are supposed to be found in the 
standard gnustep layout locations found from the root path you have set.
By default the root path is /usr/GNUstep (though you can configure the root of 
the layout to be somewhere other than /usr/GNUstep)

Most headers installed in the 'gnustep' layout will be in 
/usr/GNUstep/Local/Library/Headers and make will find them automatically.

It sounds like you have configured for the 'gnustep' layout, but are expecting 
to find resources in the old layout.  If you did, that would be bad (the two 
different installations would be interfering with each other;  not often 
obvious with headers, but when you have different versions of libraries built 
for different runtimes that's a real problem), so hacking flags to point to a 
different installation is a dangerous thing to do.

If you want the 'fhs' (headers in /usr/include) layout then that's the way you 
should configure gnustep-make.

Re: Debian12 repository.

[Andreas Fink]

see http://repo.gnustep .ch/

I am currently fighting with /usr/GNUstep/System/Tools/gnustep-config while 
compiling my own libraries

After changing the layout to gnustep

the tool is not found in the path. a symlink to /usr/bin/gnustep-config fixes 
this (or expanding the path)
However  gnustep-config  --objc-flags  does not include  a 
-I/usr/include/GNUStep  so  is not found

It's not strictly necessary for pure objc code but for gnustep-base code it is. 
There is however no --base-flags but only --base-libs.

I could simply add -I /usr/include/GNUStep   to my Makefiles. But then why have 
a config tool when it only does half of the work.

Suggestions?



> On 24 Nov 2023, at 13:39, H. Nikolaus Schaller  wrote:
> 
> 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 > >:
>> 
>> gnustep2 sounds logical as its a logical upgrade path from old non arc.
>> 
>> 
>> I have built it that way now on 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 >> > 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 >>> >:
 
 The question now is what naming to choose
 
 gnustep2...?
 gnustep-arc..?
 gnustep-clang-... ?
 
 
 
> On 24 Nov 2023, at 11:04, Riccardo Mottola  > 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 

Re: Debian12 repository.

[H. Nikolaus Schaller]

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 :
> 
> gnustep2 sounds logical as its a logical upgrade path from old non arc.
> 
> 
> I have built it that way now on 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  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 :
>>> 
>>> The question now is what naming to choose
>>> 
>>> gnustep2...?
>>> gnustep-arc..?
>>> gnustep-clang-... ?
>>> 
>>> 
>>> 
 On 24 Nov 2023, at 11:04, Riccardo Mottola  
 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, 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 

Re: Debian12 repository.

[Andreas Fink]

gnustep2 sounds logical as its a logical upgrade path from old non arc.


I have built it that way now on 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  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 :
>> 
>> The question now is what naming to choose
>> 
>> gnustep2...?
>> gnustep-arc..?
>> gnustep-clang-... ?
>> 
>> 
>> 
>>> On 24 Nov 2023, at 11:04, Riccardo Mottola  
>>> 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, 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 

Re: Debian12 repository.

[H. Nikolaus Schaller]

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 :
> 
> The question now is what naming to choose
> 
> gnustep2...?
> gnustep-arc..?
> gnustep-clang-... ?
> 
> 
> 
>> On 24 Nov 2023, at 11:04, Riccardo Mottola  
>> 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, 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 

Re: Debian12 repository.

[Andreas Fink]

The question now is what naming to choose

gnustep2...?
gnustep-arc..?
gnustep-clang-... ?



> On 24 Nov 2023, at 11:04, Riccardo Mottola  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, 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

Re: Debian12 repository.

[Riccardo Mottola]

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, 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