> Am 18.10.2023 um 00:15 schrieb Daniel Boyd <[email protected]>:
>
> 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 <[email protected]>
>> 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
