Re: Brutal review…

[H. Nikolaus Schaller]

> Am 18.10.2023 um 00:15 schrieb Daniel Boyd <danieljboyd@icloud.com>:
> 
> Yeah you're right -- that was oversimplifying.
> 
> I think you need several metapackages
> 
> metapackages for running gnustep apps
> gnustep -- synonym for gnustep-clang (at least I think that should be the 
> default)

No, if you apt install lxde or xfce4 or mate or ... it is simply a metapackage 
not for running apps but a full preconfigured desktop including some default 
setup and apps like Terminal, web browser. That is the best user experience.

So it should be a package that installs gnustep desktop eonvironment. I.e. 
base, gui, gap apps, etc. which can be grouped in other metapackages (e.g. 
gnustep-core, gnustep-gap)

And then there should be gnustep-dev for being able to develop packages. Which 
will be best developer experience.

> gnustep-gcc
> gnustep-clang
> 
> metapackages for developing gnustep apps
> gnustep-dev (installs gnustep-clang-dev)
> gnustep-gcc-dev
> gnustep-clang-dev
> 
> And then that way if you're developing an app that requires libobjc2, you can 
> just add gnustep-clang as a dependency. (I'm not sure gcc/clang is the best 
> approach. objc1/objc2 might be better...? Regardless, I think you name it 
> whatever would be most obvious to someone new to the project.)
> 
>> On Oct 17, 2023, at 4:39 PM, Riccardo Mottola <riccardo.mottola@libero.it> 
>> wrote:
>> 
>> 
>> Hi,
>> 
>> Daniel Boyd wrote:
>>> 
>>> Project goal should be for the instructions to get a working gnustep 
>>> environment (in Debian) to be as simple as:
>>> 
>>> > sudo apt install gnustep
>> 
>> that's oversimplifying, but something along a couple of virtual packages 
>> like "gnustep core" "gnustep development" "gnustep games" "gnustep net 
>> apps" (if we had more than gnumail...)could do.
>> A "gnustep full" is a bit overkill, but for whom wants it would be also 
>> easy to do. I don't know how xfce or gnome do things nowadays, because I 
>> always go the "cherry-pick" route there too.

They do it all the overkill way :)

>> 
>> These would just pull in the proper selection of packages which should 
>> be separately available. Not even that hard, even on debian. Debian has 
>> most stuff already, except some long-standing missing things.
>> 
>> With our private repo, even easier then. A thing to remember would be to 
>> make them incompatible with the offical debian packages or something 
>> similar, do be sure that they don't get mixed up.

It is easy to mix public and private repos.

Just my 2cts

-- hns