Il 11/01/2025 16:38, Ahmad Khalifa ha scritto:
At a basic level I think almost everyone starts by trying some basic packaging outside the packages for the official repositories, so it can be good to aim first at creating the package, but maybe with something that is both the most complete and up-to-date, and also the simplest and fastest for very basic cases.On 11/01/2025 12:49, Fabio Fantoni wrote:Write on Google "Debian create new package" and first result: https:// wiki.debian.org/HowToPackageForDebianIt points to various parts but mainly the more probable start point seems https://wiki.debian.org/Packaging/IntroTo point to git and gbp seems more useful https://wiki.debian.org/ PackagingWithGit Here wrote also about DEP14, tell writing first package out of git and after import, in fact it is not simple and fast to create the initial package starting immediately from git and neither to use immediately gbp and also DEP14, to create immediately on salsa etc... I remember that the last packages created new some time ago I had to do many steps, workarounds and only after convert the branches to the DEP14 names.I just went through this learning process, and IMO, first thing to learn is how to "package" (debuild, debhelper, lintian, sbuild, devscripts), then you learn how to "publish" it (dput, gbp, DEP-14).Packaging/Intro wiki is still an excellent first read if only to get the terminology in use (upstream tarball, source package, dsc, ...).To quote from PackagingWithGit wiki:It is easiest to first create the first version of a package, outside of Git.It's an advanced wiki, not a starting step for newcomers.
The problem is that it seems to me that there is not enough predisposition towards git, gbp, salsa and salsa-ci for those who want to package for Debian.
There are also cases of people who just want to package their software quickly and fairly well for Debian as well as for other distros, for Debian they find themselves having to invest days learning and wait maybe months to MAYBE have the package included while in a few hours maximum they manage to prepare it for other distros and manage to include it in a shorter time.
There are those who want to start contributing with small things or start trying and find themselves in difficulty and "wasting" time without seeing results and often giving up.
Doing it in git from the beginning can be very useful for reviews, seeing changes etc... when I looked at some packages in mentors there was a significant difference between seeing the differences between uploading to download from mentors and packages on git(even if not salsa). It is faster to review, comment specifically, and possibly help fix/improve directly.
Another difference for maintainers can be managing Debian patches, in many cases they are not needed but where they are needed there can be also a good difference in the time that can be saved with gbp-pq rather than manually with quilt in some cases. I too, despite having used gbp for years, out of habit, continued to manage patches with quilt manually and only recently with gbp-pq, noticing that I could have saved a lot of time in some cases.
And also regarding testing the changes you make there is a big difference in time (and I suppose also much less difficulty or discouragement in many cases) than preparing ideal environments and/or doing it manually locally and use salsa-ci. Having local environments and tools is useful for most cases but they are quite a few things and can take a long time, while starting to see something concrete in a very simple and fast way I suppose can reduce premature abandonment. Then maybe I could be wrong and most of the cases of abandonment are for others, like some cases seen years ago that seemed to me to be due to lack of reviewers and sponsors on mentors.
Starting to use certain things from the beginning can favor them (unless you need something different specific to the team and/or packages), but if you start by spending a lot of time with certain tools and procedures, changing later is more averse or discouraged, perhaps without imagining the advantages it can have.
So in general it's ok when you start to see mainly the packaging files themselves (both a quick and simple thing, and all the advanced things in detail, in an optimal documentation) but shortly after if you want to start contributing and/or packaging something new it's useful to have something more targeted (again both a quick and simple thing and the advanced and detailed things).
An example, a person has some basic knowledge of packaging but now wants to contribute to package a new package for the official repo, he should find information that helps him understand if the package would fit into a team and be able to get there, otherwise some information to be able to start in a simple, fast but also optimal way. It could be perhaps (I need to retry with updated docs and latest versions to check)... see "here" to start creating the initial packaging perhaps download the upstream software, procedure with dh_make and first manual changes to debian files, then prepare on git in a simple and fast way with gbp and upload it to salsa to make it easier and faster to have it reviewed and keep track of the changes and also use salsa-ci to do immediate tests (then in some cases it is necessary to see in local environments and in all cases it will be necessary to test it locally). He can also see something to fix or improve without need to wait a review and fix/improve the package to make it faster for review (that in addition to saving time and can concentrate on more advanced parts not spotted on tests rather than wasting a lot of time listing maybe many basic things to fix).
I don't know if I can explain myself well but I tried. It's also possible that he has the wrong idea about what might be useful to foster new maintainers (and more help from reviewers/sponsors).
OpenPGP_signature.asc
Description: OpenPGP digital signature
