Why are fetching from the web archive? The Epson link is versioned and seems fine?

It's been a while since I started developing this derivation and had been using it locally for quite some time without any problems.
But sometime in 2024, the Epson link returned a 403 error when accessed without a browser.
In September 2024, I then asked for help in the chat (just for the sake of completeness, here is the link: https://matrix.to/#/!RRerllqmbATpmbJgCn:nixos.org/$UlvZEGmFxF4bEMX2x68dl_0NKQcYNeNMkrLEacxbe88?via=lossy.network&via=matrix.org&via=tchncs.de) and was given the advice to add and use the archive.org link.
Currently, the Epson link does not seem to generate a 403 error, but I will check again.

Can I just leave both links there? The hash is the same, if I'm not mistaken.

Ah, I see. Please add a comment saying the EPSON link may be unreliable, but you can leave both links.

Nit: stdenv.mkDerivation supports a new pattern for recursively accessing its own values. Switching to that pattern will avoid some common pitfalls regarding recursive attribute sets. You'll then be able to access this derivation's values by prefixing them with finalAttrs, like this:

{
  tag = "v${finalAttrs.version}"
}

Don't forget the closing parenthesis at the end of the file.

Thanks for pointing that out. It's been a while since I started developing this derivation and had been using it locally for quite some time.
I've changed it as suggested and am now using the new pattern.

This information can be found in meta.license already.

Thanks for pointing that out. I've changed it as suggested.

Markdown is supported!

Good to know. I've changed it as suggested.

Avoid interpolating the pname attribute. Ideally, a downstream user can change the pname attribute using overrideAttrs without altering the output of the derivation in any way.

Please also remove other uses of pname in the rest of the derivation.

Good to know and thank you for pointing that out. I have removed all other uses of pname as suggested.
That surely also applies to the use of pname at the end of meta.longDescription, where it says drivers = [...];. Is that correct?

Since the pname is epson-inkjet-printer-workforce-840-series, could this be moved to pkgs/by-name/ep/epson-inkjet-printer-workforce-840-series/package.nix?

Oh yes, that's right.

Somehow I got a little confused: All other Epson drivers in pkgs/by-name/ep/ seem to have removed the inkjet-printer part from the pname and used pkgs/by-name/ep/epson-foobar/ and not pkgs/by-name/ep/epson-inkjet-printer-foobar/, so I also used pkgs/by-name/epson-workforce-840-series/, but did not shorten the pname.

So, what is better? Leave the inkjet-printer part in the package name as in the rpm package or in the AUR package, or follow the other Epson nixpkgs derivations and choose epson-workforce-840-series as the pname?

Is there a guideline? A preferred naming scheme?

Thanks in advance.

The package naming guidelines state that pname should always follow upstream's naming scheme, and the attribute name should be identical to pname, unless pname is an invalid identifier in Nix.

The other packages are in the wrong. Keep inkjet-printer.

Could you add comments (either here or in the .patch files themselves) about what these patches are supposed to do, and what do they fix?

Both patches fix errors that occur when building with GCC 14.

• eps_raster_print-cast.patch fixes error: passing argument 5 of ‘eps_raster_print’ from incompatible pointer type in file raster_to_epson.c

• include-raster-helper.patch fixes error: implicit declaration of function in files pagemanager.c and raster_to_epson.c

Are there any guidelines for naming patches? A preferred naming scheme?

Is a comment with the above explanations about the patches in the derivation above the section patches = [...] okay? Or is a comment in the respective .patch file better? I guess it's a matter of taste.

I am currently unaware of whether and where the patches can be fetched from. Therefore, they are added to the Nixpkgs repository (the same patches are used by the epson-workforce-635-nx625-series package, which is where they come from).

Is a comment with the above explanations about the patches in the derivation above the section patches = [...] okay? Or is a comment in the respective .patch file better? I guess it's a matter of taste.

Either is fine; I'd prefer the former since you don't need to leave the .nix file to get all of the information needed.

I am currently unaware of whether and where the patches can be fetched from. Therefore, they are added to the Nixpkgs repository (the same patches are used by the epson-workforce-635-nx625-series package, which is where they come from).

Thankfully git is really good with deduplicating text, so it's fine to copy the patches. (and the comments in that package's package.nix file if there are any)

Could this be an issue caused by unpacking the tar files without preserving the permissions of the files contained within?

I don't know. All I can say is: When I started developing this derivation, I based it on the .spec file of the rpm package, the PKGBUILD of the AUR package, and, to a large extent, the nixpkgs derivation pkgs/by-name/ep/epson-workforce-635-nx625-series. I adopted the preConfigure part from the latter and never questioned it.

But it seems that it's not necessary at all. If I leave it out, the derivation still builds.

So that part will be removed.

For cross-compilation reasons, use hostPlatform to figure out the platform we're trying to build this package for.

Good to know, and thanks for the tip.

When I look at stdenv.hostPlatform using nix repl, there are several possibilities: In addition to stdenv.hostPlatfom.system with a string as its value, i.e. “x86_64-linux” or “i868_linux”, which is checked for equality, there is also stdenv.hostPlatform.{isx86_64,isi686} with a boolean value of true/false.

Is it a matter of preference which one you use, or is one usually preferred over the other?

It depends on the situation. Some situations are better served with a string, others with a boolean. Up to you, but since this is an if statement, the isArch booleans should be more compact.

Shoving generically-named files into $out/share/doc might cause conflicts with other packages when an Nix environment is built.

Thanks for pointing that out. I will adjust the docdir accordingly.

Just so I understand: When I look at the PKGBUILD from the AUR package, the package name is part of the path to the documentation, since ${pkgname} is part of the path. When I look at the .spec file of the rpm package, the package name is part of the path to the documentation, although it is more difficult to recognize with %{buildroot}%{_docdir}, but %{buildroot} should in turn contain %{pkgtarname}-%{version}-%{release} as part of it. Is that correct?

And one more question for me to understand: With NixOS, by using $out, which already includes epson-inkjet-printer-workforce-840-series as part of the path in the store, is it still possible to have a conflict with documentation files of the same name from other packages? I'm just curious and eager to learn.

Thanks in advance.

Just so I understand: When I look at the PKGBUILD from the AUR package, the package name is part of the path to the documentation, since ${pkgname} is part of the path. When I look at the .spec file of the rpm package, the package name is part of the path to the documentation, although it is more difficult to recognize with %{buildroot}%{_docdir}, but %{buildroot} should in turn contain %{pkgtarname}-%{version}-%{release} as part of it. Is that correct?

I don't actually know; I'm not familiar with the specifics of RPM and PKGBUILD packaging.

With NixOS, by using $out, which already includes epson-inkjet-printer-workforce-840-series as part of the path in the store, is it still possible to have a conflict with documentation files of the same name from other packages? I'm just curious and eager to learn.

Not inside the store, thankfully; the hashed store paths prevent any conflicts. The issue happens when merging paths into a NixOS environment. The store paths are then stripped, and everything is combined inside a given directory so it can be used in the actual system. (usually /run/current-system)