Control: owner -1 ! Adam,
On Tuesday, September 3, 2024 9:44:36 PM MST Adam Danischewski wrote: > Still looking for a sponsor for Bashbro, it's a really useful tool. I’ll review and sponsor the package. The first thing I noticed is that the packaging repository mirrors things from the upstream repository that aren’t needed (and get in the way) and also is not efficient for handling future Debian updates. The following comes with a warning: there are a lot (a lot, a lot) of ways to maintain a Debian packaging repository. Some of them have very good reasons for existing. Many of them exist for historical reasons (they had a good reason at some point in the past and now it is a lot of work to change so they don't). For the purpose of simplicity, I am going to describe just one repository design to you without any analysis of any of the other options. I do so because this has become the current, most popular design. If you want a list of other options, just ask (and lots of people on Mentors will be willing to give you their favorites). What I am going to recommend to you is gbp (git-buildpackage). Gbp organizes your repository into three main branches. Because this is Debian, there is huge debate about what these three branches should even be called, but for simplicity’s sake I will give you the names as the gbp program currently creates them by default. master upstream pristine-tar Master contains the upstream source code combined with the debian directory. It is helpful to have these combined if you ever need to manage quilt patches. This branch contains tags for each Debian release. Upstream contains just the upstream source code, with tags for each upstream release. Pristine-tar can be used to generate the original upstream tarball (necessary for building the package) without the need to make a request to the upstream server (which might go offline at some point). This means that gbp can build any version ever released on Debian just from a clone of the packaging repository, even while offline. The gbp program will create and manage these repositories for you. https://tracker.debian.org/pkg/git-buildpackage I would recommend that you wipe out your current Salsa repository and create a new one using gbp. To do this, follow the instructions at: https://wiki.debian.org/PackagingWithGit#Importing_upstream_as_tarballs Basically, build the package locally, which will create a .dsc file. Then run: gbp import-dsc /path/to/package_0.1-1.dsc This will create a directory with a local git repository with the three branches listed above. You can then push that to Salsa. The beauty of gbp is that it makes updating to new releases very easy: gbp import-orig --uscan dch gbp buildpackage gbp tag gbp push gbp import-orig --uscan: This uses uscan to check for upstream updates, downloads them, unpacks them, tags them, and updates the three branches. dch: This edits the changelog. That is the only file in the debian directory that will need to be changed with every release. Obviously, if other files need to change, they should be edited at this stage as well. gbp buildpackage: This builds the package. Obviously, if there are any errors, they need to be fixed at this stage. gbp tag: This tags the Debian release. gbp push: This pushes all three branches and their tags to Salsa. From there, I can pull the branches, run gbp buildpackage, (check for any problems), and sponsor it. All of these program have command line switches that do extra stuff. For simplicity’s sake I have left those out of this description, but they are available in the man files (and gbp often will prompt you if one is mandatory based on the circumstances). If you have any questions, just feel free to ask. -- Soren Stoutner so...@debian.org
signature.asc
Description: This is a digitally signed message part.
