discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Brutal review…


From: Daniel Boyd
Subject: Re: Brutal review…
Date: Wed, 18 Oct 2023 08:35:34 -0500

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]