On Thu Aug 15, 2024 at 10:38 PM BST, Dmitrii Odintcov wrote:

The existing tutorials on `equivs` tools are few and not very
detailed, so I'm looking for some clarification.

What do `equivs-control`/`build` do beyond what can already be
accomplished with a `DEBIAN/control` file and `dpkg --build`?

Nothing, really. They in theory make the process easier/smoother.

I've long felt that they were overcomplicated in themselves: the
ideal UX should be not much more than "equivs package-name" => ./package-name.deb generated, IMHO. I once had ambitions to add
that UX (either as a patch to equivs, or as a separate equivs-ng)
but I never got around to it.


--
Please do not CC me for listmail.

👱🏻 Jonathan Dowland
✎ [email protected]
🔗 https://jmtd.net

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Aug 18, 2024 at 17:08:00 +0100, Jonathan Dowland wrote:

I've long felt that they were overcomplicated in themselves: the
ideal UX should be not much more than "equivs package-name" => ./package-name.deb generated, IMHO. I once had ambitions to add
that UX (either as a patch to equivs, or as a separate equivs-ng)
but I never got around to it.

That may be acceptable for packages that don't have any Depends: or
Provides: lines or what-have-you.

In general, people may be using equivs for a variety of reasons --
for example, a custom local package that depends on all of the packages
needed for a specific server installation.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun Aug 18, 2024 at 5:32 PM BST, Greg Wooledge wrote:

On Sun, Aug 18, 2024 at 17:08:00 +0100, Jonathan Dowland wrote:

I've long felt that they were overcomplicated in themselves: the
ideal UX should be not much more than "equivs package-name" => ./package-name.deb generated, IMHO. I once had ambitions to add
that UX (either as a patch to equivs, or as a separate equivs-ng)
but I never got around to it.

That may be acceptable for packages that don't have any Depends: or
Provides: lines or what-have-you.

I would want this for packages which had depends/provides as well: my expectation would be that the generated dummy package would also have
those depends/provides. It must not have been clear from my brief
illustration, but my envisaged "equivs" tool would look up the package
name from dpkg metadata.

--
Please do not CC me for listmail.

👱🏻 Jonathan Dowland
✎ [email protected]
🔗 https://jmtd.net

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Aug 20, 2024 at 12:26:39 +0100, Jonathan Dowland wrote:

On Sun Aug 18, 2024 at 5:32 PM BST, Greg Wooledge wrote:

On Sun, Aug 18, 2024 at 17:08:00 +0100, Jonathan Dowland wrote:

I've long felt that they were overcomplicated in themselves: the
ideal UX should be not much more than "equivs package-name" => ./package-name.deb generated, IMHO. I once had ambitions to add
that UX (either as a patch to equivs, or as a separate equivs-ng)
but I never got around to it.

That may be acceptable for packages that don't have any Depends: or Provides: lines or what-have-you.

I would want this for packages which had depends/provides as well: my expectation would be that the generated dummy package would also have
those depends/provides. It must not have been clear from my brief illustration, but my envisaged "equivs" tool would look up the package
name from dpkg metadata.

This is getting weirder.

You're saying that you use equivs to create packages that have the SAME
NAMES as Debian packages??

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue Aug 20, 2024 at 1:55 PM BST, Greg Wooledge wrote:

You're saying that you use equivs to create packages that have the SAME
NAMES as Debian packages??

That's entirely the point of it, surely. You want to convince the
packaging system that you have dependency $FOO satisfied, even if you
don't. You create an "equivalent" metapackage.

As it happens I haven't used it for years, and if I had the need, I'd
probably hand-craft a package source, because that's easier to me than
figuring out the equivs incantations (which is exactly why I envisaged a
better UX).

I last looked at it seriously when I wrote game-data-packager, which
does something in the same space, in 2006 (I had to look that up).

--
Please do not CC me for listmail.

👱🏻 Jonathan Dowland
✎ [email protected]
🔗 https://jmtd.net

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Aug 21, 2024 at 11:57:06 +0100, Jonathan Dowland wrote:

On Tue Aug 20, 2024 at 1:55 PM BST, Greg Wooledge wrote:

You're saying that you use equivs to create packages that have the SAME NAMES as Debian packages??

That's entirely the point of it, surely. You want to convince the
packaging system that you have dependency $FOO satisfied, even if you
don't. You create an "equivalent" metapackage.

The only way I've used equivs is to produce a package named mta-local
which looks like this:

hobbit:~$ dpkg -s mta-local
Package: mta-local
Status: install ok installed
Priority: optional
Section: misc
Installed-Size: 9
Maintainer: Equivs Dummy Package Generator <[email protected]> Architecture: all
Multi-Arch: foreign
Version: 1.0
Provides: mail-transport-agent
Conflicts: mail-transport-agent
Description: A local MTA package
A package, which can be used to establish a locally installed
mail transport agent.

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.

The idea that I would do this but name it something like "sendmail"
instead of "mta-local" sounds extremely sketchy.

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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
✎ [email protected]
🔗 https://jmtd.net

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)