On Wed Aug 21, 2024 at 12:47 PM BST, Greg Wooledge wrote: > The only way I've used equivs is to produce a package named mta-local > which looks like this:
Yes, there's a distinction between satisfying a virtual dependency, like mta-local, and the use I outlined. The virtual dependency one is probably more common. > It provides mail-transport-agent, so programs like bsd-mailx have their > dependencies satisfied. > > I run a locally compiled qmail installation, not from the Debian packages, > if such packages even still exist. I saw some discussion on the Fediverse earlier this year from some DD who wanted to re-introduce qmail to Debian. I don't know if they are still working on it. > The idea that I would do this but name it something like "sendmail" > instead of "mta-local" sounds extremely sketchy. It does introduce other things to worry about. E.g. version issues. > As I said previously, I know some other people use equivs to generate > a package of their own making that contains a bunch of Depends lines, > to bring in all of the software they want during a new installation. > In that case, it would also not make sense for their locally built > package to share a name with any Debian package. That's an entirely different (and just as valid) use-case for a dummy package generator. It's straying somewhat from "equivs" (equivalent to what?), but should be serviced by something, be that equivs or something else. Which reminds me (old memory pages being slowly loaded from 2006 disk) of another thing about equivs that irked me, but has been fixed (in 2010! #475936): it used to be implemented in terms of higher-level tooling built on top of dpkg-dev, which pulled in more dependencies than ideal. (It now uses dpkg-buildpackage from dpkg-dev. I had thought it could use dpkg-deb directly, and not require even dpkg-dev, but perhaps some of the features I don't use have requirements beyond what can be done that way.) -- Please do not CC me for listmail. 👱🏻 Jonathan Dowland ✎ j...@debian.org 🔗 https://jmtd.net
