The issue is that the debian packages are depending on gcc while most use clang with ARC for todays builds with the new runtime. Thats still an open point. I personally build my own debian packages since a while for Debian 10 & 11 and now also Ubuntu 22.04LTS on x86_64 and arm64 so I can pull it from my own Repo for my own projects. I would like to use the standard repo versions but for me not having support for ARC and clang makes it impossible.
While I understand some folks still want to be backwards compatible with gcc installs, what about a separate tree with arc/clang support? does that work with debian standard repo or does it all still require to be workable with gcc? I will look into gdp now... my builds are done with simple shell scripts... > On 25 Dec 2021, at 13:14, Steven R. Baker <ste...@stevenrbaker.com> wrote: > > Heya folks, > > I've been following the other threads, but haven't been computering as > actively over the holidays, so I wanted to give an overview and "source of > truth" on the Debian packages of GNUstep. > > Sorry for the long one, but I'm aiming to give a background on the "how and > why" of Debian packaging; the current state of things; how to get newer > version of things; and how to help. > > I intend to make a README for GNUstep in Debian and publish it, and a lot of > what is here will go there. But for now, you'll have to wade through this > email. > > Background: Debian packages are often considered "wildly out of date," and > this is only true because of the way the Debian release process works. > > Debian has three "current" distributions. "stable", which is the current > released version. "unstable" (called sid, which is a backronym now meaning > Still In Development) is where new package versions are uploaded. Many > daily-drivers of Debian use "testing", which is unstable packages delayed by > a period of time (two weeks from memory) and only "promoted" to testing when > there aren't any release critical (RC) bugs reported against them. > > The Debian packages are maintained by the Debian GNUstep packaging team, > which is sorely understaffed. > > You can find the repos for the packaging efforts on Debian Salsa, which is > Debian's GitLab instance: https://salsa.debian.org/gnustep-team Every > GNUstep related package that is in Debian (or will be RSN) is included there. > > Let's use an example to demonstrate the current state of things, gnustep-base > which can be found here: https://salsa.debian.org/gnustep-team/gnustep-base > > The `master` branch contains the release that is currently in sid. In the > case of gnustep-base, that's 1.28.0. But here's where it gets interesting. > Using the Debian watch program, the GNUstep FTP server is monitored for new > releases. You can see the watch file here: > https://salsa.debian.org/gnustep-team/gnustep-base/-/blob/master/debian/watch > > There are also branches called `stretch` and `buster` which is the source > from which the packages in those releases is built. > > Debian Salsa should grab the latest release when it hits the FTP server and > create a new branch. > > If you check out that repo and build the package (more details later, but try > `debuild -uc -us` to start) you should get a working package. If you don't, > you need to look in `debian/patches` and see if the patches need to be > updated or removed to get it to build appropriately. > > If you make changes, PLEASE submit a merge request so someone on the GNUstep > packaging team can review it and include it. > > The tool for building packages from the GitLab sources is called `gbp` and is > in the `git-buildpackage` package. You will have to do some setup, there is > documentation. > > So, how can you help? > > 1) Please learn about gbp and look at the repositories to see if > anything is missing a latest version. If it is, we need to update the > CI/DevOps stuff in GitLab to do this automatically. > 2) Build and test the latest versions of things. > 3) Create new packages for things that don't exist. > > My intention is to use these sources to build a new repository of up-to-date > packages, and add some missing things (libs-xcode, buildtool, and some apps.) > I have made some progress on this, and intend to get back to it in the new > year afresh. > > The best next-step for us is to maintain a repository (I am volunteering for > this in the new year) that contains good packages of the latest-released > stuff. So people can simply add a new package repository and get latest > GNUstep bits. > > If you have questions or concerns, please reply in thread. It will really > help me finish outlining my documentation for this. > > I hope this helps a bit. > > Cheers! > > -Steven > >
