> On Wed, Jun 07, 2023 at 09:27:47PM -0700, Bryce Harrington wrote:
> > On Wed, Jun 07, 2023 at 06:41:14PM -0700, Steve Langasek wrote:
>
> > It does not exist, actually! I recall we dropped it a few years ago,
> > see see f2dc622e.
>
> $ git-ubuntu help
> usage: git-ubuntu [-h] <command> ...
> git-ubuntu: error: argument <command>: invalid choice: 'help' (choose from 'build', 'build-source', 'import-local', 'import-ppa', 'lint', 'review', 'clone', 'export-orig', 'import', 'importer-service-broker', 'importer-service-poller', 'importer-service-worker', 'merge', 'prepare-upload', 'queue', 'remote', 'submit', 'tag')
> ^^^^^
> $
Heh, that list is pretty out of date. build-source is gone, and I think
review and lint are as well. There is still a 'build' module with some
of the remaining code from the original build command, but you can see
from the above commit that the hook for the command was removed.
> > That said, though, I've wondered if 'build' may not necessarily be the
> > ideal jargon, anyway. Since the (prepare-upload args) step can trigger
> > a git push, and because this is done principly when uploading, it feels
> > more like a submission-style workflow than a build; "build" also implies
> > you're creating some form of artifact for local use, which in this case
> > you're not, really.
>
> > So, I'd suggest that even though 'git-ubuntu build' is not used, you may
> > still want to think more anyway about if there's a better term.
>
> Related commands:
>
> - dpkg-buildpackage
> - debuild
> - gbp buildpackage
> - bzr builddeb
> - sbuild
>
> So "build" is quite a strong theme in the existing tools.
>
> An interesting point, though, is that this makes me realize I would only
> ever care about the sauce this provides when preparing a source package for
> upload to Ubuntu, and not when I was trying to do a binary package build.
> Another previous git-ubuntu subcommand was 'git-ubuntu build-source'. Do
> you think that would be a better fit?
That occurred to me too. We had subsumbed 'build-source' to 'build -S'
since both commands used basically the same code just passing the -S
along to the underlying tools.
> I don't think 'submission-style' quite describes what I'm expecting to
> achieve here. I might want to build a source package, then do a variety of
> things with it before actually uploading it; e.g. run a debdiff against the
> previous package to be sure it's actually a clean diff at that level, take
> the source artifacts and do a test build, push to a ppa before pushing to
> the Ubuntu archive, manually mangle the .changes file (rare, but I happen
> to have just done this for a series of SRUs so that they would have complete
> changelogs but not link to a whole list of unrelated bugs in the SRU
> process), etc. And the target of the 'git push' may or may not be something
> that we want to merge immediately, may or may not want to raise an MP for
> immediately.
Right, the point I was making there is that since the 'prepare-upload'
step pushes the branch to Launchpad, I don't want or need to include
that in my workflow until the end, after all that is done and I'm ready
to do the .changes upload. Then I do one final debuild -S and run
prepare-upload, verify it worked and check the .changes file has
expected fields, and then I directly dput the .changes. I think of that
as more of a submission-style procedure.
But, there's more than one way to do this. I'm sure we all have unique
workflows for how we prep source packages.
Bryce
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
