Hi Juan, Le 30/12/2025 à 23:49, Juan Mendez a écrit :
> This is an interesting package (I am interested in all things related to > browser engines, particularly Chromium-based ones). I don’t have time to> review this package right now. I hope that someone else does. But, if you > don’t get a response in a couple of months, please hit me up and I will take a> look at it if I have time then. Thanks Soren, I really appreciate the interest. No rush - I'll follow up in a couple of months if needed. The packagesare available at debian.vejeta.com <http://debian.vejeta.com> for anyone who wants to test in themeantime. Regards, Juan
First, thanks for working on that package. It is nice to see there is some effort being done on it. As I wrote previously, I am interested in scilab, of which upstream is relying more and more on JCEF, the Java wrapper around cef.
Please let me start with some thoughts I have had for months about cef.I wonder if we really need the whole source of chromium or if the headers (plus the shared libs in chromium-common maybe) are enough, as we would do if we build against the -dev package of a regular C++ library. Some months ago I issued a chromium-headers package from src:chromium and tried to build against is. I think we can build the package in a lighter way than the upstream's one, by just calling some of the scripts to configure the package. Please find attached the debian/ directory of my attempt to package cef, using it I am able to build some things but curiously the target libcef.so is not produced, I don't know why...
I would be really interested in your opinion about the headers being enough or not. Once they are installed under /usr/include, I think they can be included from the cef sources.
Back to your work now.- The package is not native, as it is not Debian-specific and relies on an upstream orig tarball. If you want to add other tarballs, use instead a multiple upstream tarball package (look for ``MUT'' in the manpage of uscan). I think it will also allow you to patch all the needed files at once using the regular quilt mechanism.
- about the rust-toolchain tarball you need: is it packaged in Debian?- certainly we can modify the build process (a bit like in my attached attempt) to completely get rid of depot_tools. Anyway we cannot clone anything nor access the Internet during a package build. (I see git clone commands under override_dh_auto_build).
- there are multiple binary files (at least in depot_tools), including Windows-related ones: simply remove them using the repacking mechanism of Debian packages.
- There are lots of copyright holders to list in debian/copyright, I see for instance Chris Moyer, Robert Mela, Mitch Garnaat, Amazon.com, Eucalyptus Systems, Google, Nexenta Systems, Blue Pines Technology, ... perhaps writing the final debian/copyright file is not the first thing to do, still.
- When designing the MUT package, you will have to introduce a debian/watch file.
- debian/rules: is it correct to say this file mimics the build documentation on the cef website, plus some extra work for applying the patches?
SummaryThanks again for addressing this huge package. Maybe we should discuss a bit things with the Chromium Team and the people implied in the discussion in the bug report of #893448, to see what is the correct way to go: if a new chromium-headers binary package is enough, we should go for it. But maybe I am completely missing something.
I think designing a MUT package is a good way to go if it appears we absolutely need the chromium sources. Have a look at my packaging attempt to estimate if we can get rid of depot_tools, that would help a lot.
Additional feedback from more experienced people, e.g. from the Chromium Team, would be very useful.
All the best, -- Pierre
Attachment:
debianDirCef.tar.xz
Description: application/xz
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature