jesec-rtorrent: 0.9.8-r15 -> 0.9.8-r16

[winterqt]

Description of changes

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 22.05 Release Notes (or backporting 21.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[winterqt]

@AndersonTorres I do wish there was some way we could clean up the usage of jesec-rtorrent and rtorrent-jesec in top-level. Since the name of the packages have the jesec- prefix, I think it would make sense that pkgs.jesec-rtorrent would work, but that's the key of the set. Do you have any suggestions?

[AndersonTorres]

There is no reason to split this line.

The reason for this is obvious: the first is a Boolean argument that controls the insertion of the second one as a dependency.

[winterqt]

I agree, except for the fact that this was the result of running the file through nixpkgs-fmt -- no formatter will be able to know this (and if Nixpkgs is auto-formatted in the future, this will happen anyways).

[AndersonTorres]

This was the only thing the formatter found? Six lines in a diff that worsens the legibility of a code?
And people ask why I don't like them...

Also formatters are not to be the last word. Machines are meant to help us, not us to help them.

[AndersonTorres]

This was the only thing the formatter found? Six lines in a diff that worsens the legibility of a code?
And people ask why I don't like them...

Also formatters are not to be the last word. Machines are meant to help us, not us to help them.

[AndersonTorres]

Do you have any suggestions?

The relevant snippet is

  jesec-rtorrent = recurseIntoAttrs
    (callPackage ../tools/networking/p2p/jesec-rtorrent {
      callPackage = newScope pkgs.jesec-rtorrent;
    });

  rtorrent-jesec = jesec-rtorrent.rtorrent;
  libtorrent-jesec = jesec-rtorrent.libtorrent;

If we just flip rtorrent-jesec with jesec-rtorrent, it should work fine.

  rtorrent-jesec = recurseIntoAttrs
    (callPackage ../tools/networking/p2p/jesec-rtorrent {
      callPackage = newScope pkgs.rtorrent-jesec;
    });

  jesec-rtorrent = rtorrent-jesec.rtorrent;
  jesec-libtorrent = rtorrent-jesec.libtorrent;

[winterqt]

I still think this is confusing considering the set name and the exposed package names at top level are so similar. I don't think there's any better solution, though...

[winterqt]

@AndersonTorres Maybe we should consider reverting the addition of the package set/scope for the rtorrent and libtorrent variations?

[AndersonTorres]

@winterqt

No problems to me.

However, do not to put libtorrent inside development/libraries/ because, well, they are not meant to be general-purpose torrent libraries...

[AndersonTorres]

LGTM, waiting ofborg.

[winterqt]

@ofborg eval

[winterqt]

@AndersonTorres Should be good now -- OfBorg passes. I did add an extra commit though, please see that before merging.