[Top][All Lists]

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

Re: The State of Debian Packaging

From: Andreas Fink
Subject: Re: The State of Debian Packaging
Date: Wed, 23 Nov 2022 09:50:13 +0100

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 <steven@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.



reply via email to

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