Re: Brutal review…

[H. Nikolaus Schaller]

Well, I have no idea how Debian upstreaming works - I just know how a private 
(or self-published) repository can work (and that it is easier to handle).

-- hns

> Am 18.10.2023 um 15:35 schrieb Daniel Boyd <danieljboyd@icloud.com>:
> 
> I know this isn’t the first time we’ve discussed getting clang-based gnustep 
> into Debian. Since Debian 12 just came out, I assume our next opportunity is 
> Debian 13? What prevented us from getting in 12 and what do we need to do to 
> get into 13?
> 
> Sent from my iPhone
> 
>> On Oct 18, 2023, at 08:20, H. Nikolaus Schaller <hns@goldelico.com> wrote:
>> 
>> 
>>> Am 18.10.2023 um 14:43 schrieb Daniel Boyd <danieljboyd@icloud.com>:
>>> 
>>> The problem with a desktop environment metapackage is that gnustep is not a 
>>> desktop environment. Window Maker *uses* gnustep, but it is not gnustep 
>>> proper. In the same way that xfce uses gtk+.
>> 
>> Yes, that is why I changed my mind to propose
>> 
>> - gnustep:    is a GUI development toolkit like gtk or qt
>>   it is a metapackage to pull in
>>   gnustep-base
>>   gnustep-hui
>>   gnustep-gcc
>>   gnustep-clang
>>   etc.
>> - gap:        a set of applications using the gnustep toolkit - one Debian 
>> package for each one
>> - gsde:        is a desktop environment using (i.e. making the package 
>> dependent on) gnustep like xfce is using gtk+.
>> 
>> Potentially it is possible to split then "gnustep" package into a runtime 
>> (meta) package that just loads compiled shared libraries and a "gnustep-dev" 
>> package that loads all the header files. And Debian source code packages... 
>> Then, "gsde" would only have to depend on "gnustep" and not on "gnustep-dev".
>> 
>>> 
>>> I think you need to strike a balance somehow. On one hand, we don’t want to 
>>> make it hard to discover gnustep apps. But on the other hand, I think it’s 
>>> important that we don’t add to the confusion about what gnustep actually 
>>> is—a framework upon which apps are built. Not the apps themselves.
>> 
>> So IMHO there is no problem at all with this and no confusion, as long as 
>> "gnustep" and "gsde" and "gap" are separated. In mind and in package names.
>> 
>> My proposal would be to just start to work instead of debating what the 
>> "best" compromise is. It is not difficult or even challenging and then 
>> improve the structure after seeing how it works in practise and where the 
>> issues are. It is not a big deal to rename packages, modify package 
>> dependencies, descriptions and contents, as long as the debian package 
>> version numbers are correctly incremented.
>> 
>> I haven't followed all discussions but if there is someone who sets up a 
>> private debian repository for all gnustep related packages and maintains it, 
>> everyone could contribute. And it just needs an additional entry in 
>> /etc/apt/sources.list or a file in /etc/apt/sources.list.d
>> 
>> -- hns
>> 
>>> 
>>> Sent from my iPhone
>>> 
>>>>> On Oct 18, 2023, at 00:32, H. Nikolaus Schaller <hns@goldelico.com> wrote:
>>>> 
>>>> Well, on second thought it is a matter of definition.
>>>> 
>>>> There could be:
>>>> gsde    - as the GNUstep based desktop (equivalent to xfce4 for example)
>>>> gnustep    - as the full and complete development system (equivalent to 
>>>> Xcode)
>>>> gap        - the GNUstep applications
>>>> 
>>>> 
>>>>>> Am 18.10.2023 um 07:11 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> 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
>>>>> 
>>>> 
>>