Sysop: | Amessyroom |
---|---|
Location: | Fayetteville, NC |
Users: | 26 |
Nodes: | 6 (0 / 6) |
Uptime: | 64:30:10 |
Calls: | 482 |
Calls today: | 1 |
Files: | 1,072 |
Messages: | 96,304 |
Package: wnpp
Severity: wishlist
Owner: Roland Mas <lolando@debian.org>
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name : gwh
Version : 0.6.14
Upstream Contact: Roland Mas
* URL : https://salsa.debian.org/lolando/gwh
* License : GPL-3+
Programming Lang: bash
Description : git-buildpackage workflow helper
This is a wrapper script around git-buildpackage
This is a wrapper script around git-buildpackage
so you have gwh, calling gbp, calling sbuild?, calling dpkg-buildpackage?, calling debian/rules, calling dh, calling dh_auto_build?, calling upstream's build system (which may itself often include layers)
i know some of these do add new features, but at some point isnt there enough wrapping?
so you have gwh, calling gbp, calling sbuild?, calling dpkg-buildpackage?, calling debian/rules, calling dh, calling dh_auto_build?, calling upstream's build system (which may itself often include layers)Please name at least 2 layers that you want to remove and describe briefly how would you do that.
i know some of these do add new features, but at some point isnt there enough wrapping?
* Package name : gwh
Version : 0.6.14
Upstream Contact: Roland Mas
* URL : https://salsa.debian.org/lolando/gwh
* License : GPL-3+
Programming Lang: bash
Description : git-buildpackage workflow helper
This is a wrapper script around git-buildpackage
I'm deeply concerned that the "surface area" of Debian packaging
tools is too large already for new folk, and adding something like
gwh into the archive makes that problem worse.
I would really like to see an effort to improve gbp itself directly
at least first. Have you tried to do that?
I try to describe, how packaging with gbp (git-buildpackage) can work, >including the workflow and why.
It should help to unterstand the process of packaging.
salsa.debian.org/ddp-team/dpb
Hi,
* Package name : gwh
Version : 0.6.14
Upstream Contact: Roland Mas
* URL : https://salsa.debian.org/lolando/gwh
* License : GPL-3+
Programming Lang: bash
Description : git-buildpackage workflow helper
This is a wrapper script around git-buildpackage
I know git-buildpackage has a lot of options and historically it has
been a little bit hard for packagers to figure out which commands
exactly to use with git-buildpackage to achieve the normal day-to-day packaging tasks, but the man pages and the manual at https://gbp.sigxcpu.org/manual/ is nowadays much improved.
Are you sure that creating a new abstraction layer on top of
git-buildpackage is useful?
You basically just have one bash script with git-buildpackage aliases
in a fancy way. Could you just contribute to upstream git-buildpackage
to make it easier, or have your script included at https://salsa.debian.org/agx/git-buildpackage/-/tree/master/examples
instead of creating a whole new Debian package?
_______________________________________________
git-buildpackage mailing list
git-buildpackage@lists.sigxcpu.org http://lists.sigxcpu.org/mailman/listinfo/git-buildpackage
As someone who is one of the most vocal supporters of standardizing
how we package things, I would like to say that I always worry when
someone says, “Don’t package this new thing. The things we have are already good enough.” I worry that attitude hinders progress, mostly because it is hard to tell which things will end up being really
useful over time.
On Wed May 21, 2025 at 12:45 AM BST, Soren Stoutner wrote:
As someone who is one of the most vocal supporters of standardizing
how we package things, I would like to say that I always worry when
someone says, “Don’t package this new thing. The things we have are already good enough.” I worry that attitude hinders progress, mostly because it is hard to tell which things will end up being really
useful over time.
This is not what I said. In particular I have not asserted that the
existing tools are good enough. (Far from it). I argued for improving
the existing tools.