[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
>>>>
>>>
>
- Re: Brutal review…, (continued)
- Re: Brutal review…, Hugo Melder, 2023/10/17
- Re: Brutal review…, Andreas Fink, 2023/10/17
- Re: Brutal review…, Daniel Boyd, 2023/10/17
- Re: Brutal review…, H. Nikolaus Schaller, 2023/10/17
- Re: Brutal review…, Riccardo Mottola, 2023/10/17
- Re: Brutal review…, Daniel Boyd, 2023/10/17
- Re: Brutal review…, H. Nikolaus Schaller, 2023/10/18
- Re: Brutal review…, H. Nikolaus Schaller, 2023/10/18
- Re: Brutal review…, Daniel Boyd, 2023/10/18
- Re: Brutal review…, H. Nikolaus Schaller, 2023/10/18
- Re: Brutal review…,
Daniel Boyd <=
- Re: Brutal review…, H. Nikolaus Schaller, 2023/10/18
- Re: Brutal review…, Daniel Boyd, 2023/10/18
- Re: Brutal review…, H. Nikolaus Schaller, 2023/10/18
- Re: Brutal review…, Andreas Fink, 2023/10/18
- Re: Brutal review…, Daniel Boyd, 2023/10/18
- Re: Brutal review…, Andreas Fink, 2023/10/18
- Re: Brutal review…, Daniel Boyd, 2023/10/18
- Re: Brutal review…, Thomas, 2023/10/19
- Re: Brutal review…, Riccardo Mottola, 2023/10/19
- Re: Brutal review…, Xavier, 2023/10/19