discuss-gnustep
[Top][All Lists]
Advanced

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

Re: Brutal review…


From: H. Nikolaus Schaller
Subject: Re: Brutal review…
Date: Wed, 18 Oct 2023 16:45:02 +0200

Yes, Hosting is not for free. Especially if high bandwidth is to be expected.

Different versions: not necessarily needed. Iknow from the QuantumSTEP repo 
that only Base (Foundation) and GUI (AppKit) have some peculiar dependencies on 
e.g. libssl, libpng, libjpeg which are different over different Debian 
releases. It is also possible to focus on one or two most recent ones.

A repo ist just a download server with some Release and Packages files. See 
here: 
http://download.goldelico.com/quantumstep/debian/dists/bullseye/main/binary-i386/
But generating the Release and Package files on a non-Debian host is 
non-trivial... On a Debian based server there are special packages to generate 
repositories.


> Am 18.10.2023 um 16:11 schrieb Daniel Boyd <danieljboyd@icloud.com>:
> 
> Downside for the private repo route is you have to pay for the hosting 
> infrastructure. And then you’ll need packages for a bunch versions of Debian 
> and Ubuntu that someone would need to curate. 
> 
> Honest question—would it be easier to do a flatpak?
> 
> Also, is there any GNU infrastructure we could leverage to host an apt repo?
> 
> Since Debian 13 is a long ways off, I do think we might want to consider the 
> private repo or flatpak route, but obviously neither of those is a trivial 
> project.
> 
> I’m happy to help with a project like that—flatpak or private repo—but I’ve 
> never done anything like that, so would need some guidance/help. 
> 
> Sent from my iPhone
> 
>> On Oct 18, 2023, at 08:52, H. Nikolaus Schaller <hns@goldelico.com> wrote:
>> 
>> 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
>>>>>>> 
>>>>>> 
>>>> 
>> 




reply via email to

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