Debian Chromium package conversion framework

[iskunk]

I have put together a set of scripts that make it possible to convert the Debian source packaging of Chromium into an equivalent ungoogled-chromium package. The end result is not only very close to what a native packaging of u-c would look like (all that's missing is u-c-specific documentation), it can be installed on the system concurrently with the original Chromium (because all the files that would otherwise conflict have been renamed).

Note that the converted package retains the original upstream source tarball used by Debian. Yet it does not require the ungoogled-chromium tooling to build, because the necessary modification logic is condensed into a script generated by the new make_domsub_script.py utility. This generated script is invoked as an additional patching operation during the package build, and its effects can also be reverted, all in accordance with Debian package policy.

By design, the delta between the Debian package and the converted one is as small and easily-reviewable as possible. I've even provided a script (compare.sh) to facilitate this. (This is why I opted against bundling the domain substitutions as a patch. No additional scripts would have been needed, but the patch was over 30 MB in size!)

The new work may be viewed in my tree here. Please have a look at it, perhaps give it a try, and let me know if you have any feedback.

Before I put together a proper PR, I would like to ask if it should land here in the contrib repo, or if this approach might be desirable for ungoogled-chromium-debian instead. I believe that the approach implemented here could be generalized to other Linux distros, allowing u-c releases to piggyback directly on the release-engineering work that the distros already perform.

[networkException]

Remarkable work!

I would imagine that the tool is pretty specific to the debian package build process, although I wouldn't mind merging this here regardless. With my "packaging team" hat on, could this be used to maintain ungoogled-chromium-debian?

[iskunk]

That was my hope, for this to be the new workflow for ungoogled-chromium-debian. To the extent that I understand the current process, it does not create proper source-package files (the original-source and debian-subdir tarballs are empty/fake), so if you wanted to build the binary .debs yourself, you're SOL. (I don't understand how OBS is building .debs from those to begin with.)

And while this tooling is specific to Debian, I think this general approach can be applied to other distros. As long as they follow the "ship pristine upstream source + our patches" workflow, the make_domsub_script solution should be similarly adaptable to their packaging processes.

Would you like me to file a PR for this in ungoogled-chromium-debian?

A couple further points to consider:

• This tooling should be amenable to automation. It should be feasible to write up an action that regularly checks the Debian archive for new Chromium packages, grabs the appropriate u-c tag, and produces the converted source package. The only additional work needed should be when there is a new conflict between the u-c patches and Debian's.
• The real goal, however, should be for Debian themselves to ship u-c. That will make it available to a much wider audience. Once this tooling is fully vetted, I'll bring up the idea with them. So far as I've seen, they love the idea of u-c, but the project hasn't been in a very "package-friendly" state (e.g. requiring the u-c package to be mutually exclusive with the regular chromium one is awkward from a distro perspective), and the maintenance burden is beyond what they can spare. I've aimed to address both those issues with this work.

[networkException]

That was my hope, for this to be the new workflow for ungoogled-chromium-debian

:+1:

And while this tooling is specific to Debian, I think this general approach can be applied to other distros. As long as they follow the "ship pristine upstream source + our patches" workflow, the make_domsub_script solution should be similarly adaptable to their packaging processes.

Would you like me to file a PR for this in ungoogled-chromium-debian?

Sounds really good, if this ends up working out with debian I'm sure we can consider a similar approach for other distributions if that improves on the workflow :D

The real goal, however, should be for Debian themselves to ship u-c.

(this one especially with my core team / platform maintenance overseeing person hat on) That would be awesome obviously, please be vocal about anything administrative you need to advance that work

[iskunk]

All right, I'll close this issue then, and open a PR in ungoogled-chromium-debian.

(this one especially with my core team / platform maintenance overseeing person hat on) That would be awesome obviously, please be vocal about anything administrative you need to advance that work

So far, the only difficulty has been reviews taking a bit of time :-]

Everything's been going smoothly. I was concerned when the Debian build configuration led to errors that others weren't seeing, opening the possibility that only the project-standard build config would be supported. But that proved not to be the case, and the team's working on a fix for the link error I encountered, so it's all good.