1. Forum
  2. Usenet
  3. LINUX.DEBIAN.DEVEL.MENTOR

  • How to name a similiar package?

    From Sven Wick@21:1/5 to All on Sun Mar 17 14:10:02 2024
    Hi,

    I maintain the package **ssh-tools**
    and upstream as well.
    These are a mix of Bash and Perl scripts.

    Recently I do more stuff with Go
    and have new tools written in Go
    and don't want to mix them with the Bash and Perl Scripts
    because that would be difficult to package (also for other Distros and OSes).

    I am not sure how to name the new tools upstream repo
    and therefore the package name.

    Currently it's ssh-toolz (with a "z")
    since I found examples like **python3-toolz**.
    But I also thought about ssh-tools2 sind there is **wget2**.

    Any suggestion what the best practice is to name similar packages?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Wookey@21:1/5 to Sven Wick on Sun Mar 17 15:10:01 2024
    On 2024-03-17 14:09 +0100, Sven Wick wrote:
    Hi,

    I maintain the package **ssh-tools**
    and upstream as well.
    These are a mix of Bash and Perl scripts.

    Recently I do more stuff with Go
    and have new tools written in Go
    and don't want to mix them with the Bash and Perl Scripts
    because that would be difficult to package (also for other Distros and OSes).

    Currently it's ssh-toolz (with a "z")
    since I found examples like **python3-toolz**.
    But I also thought about ssh-tools2 sind there is **wget2**.

    Any suggestion what the best practice is to name similar packages?

    Are the new tools replacements or additional? I don't see why adding a
    3rd language to the 2 already used makes things 'hard to package', but obviously if you want to have a separate upstream repository
    (e.g. because you want to supesede the old repository eventually) then
    that's up to you as upstream.

    I am not sure how to name the new tools upstream repo
    and therefore the package name.

    If the new stuff is intended to be a replacement then ssh-tools2 or ssh-tools-ng (for 'next generation') are typical patterns. If they are
    just more tools then ssh-tools-extra would make sense, or just keep
    them all in one package/repo as 'ssh-tools' which I think users would
    like best.

    ssh-toolz is fine as a name, but obviously users will have no idea
    what the difference between ssh-tools and ssh-toolz is, so at least be
    very clear in the long description, and give a clue in the short one
    if possible.

    And thanks for thinking about it before it's too late to fix. Names that
    are clear to users are definitely helpful.

    Wookey
    --
    Principal hats: Debian, Wookware, ARM
    http://wookware.org/

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEER4nvI8Pe/wVWh5yq+4YyUahvnkcFAmX2+NEACgkQ+4YyUahv nkfA1xAAys4selUoLNkiTu/UoZbA9lXjcaGHhoWU7u5CQ3mmJtSRVExVXdBvh0si 01eFdYljoXWcpeXpwFjO2O/5nOUQ3oXI/jyJEisMe7LdozdHx+11ZmZXuhbobRgq +RSWFuS0kv9AQijXxkMNSKvV7EZAL/bzxL/fR9a3z8Xy2uJf7dPdhMCisHg3K8Gw +4oVrcOfT3J0vbO55yINnClam4fCjaOI0/4eKsPbmZu7WDqq6xEkbCQVhmPc0ev2 TzWu/OoyvxKbopogKE1/V+ESe9SXxkoPv0/jdM5nPkwmGxoD4sYCP+sTGZA0+/9a X09ZtXKHtmnNCHPBTNf6Pfob6P0cALRRottrnMJ+ZvEd3B06HmntuvOGyDO5RGzd sauxUrVz/tWjGyGlWd+jWAAVBNQbGFavPvmRgiS0PfmfDo/b3yhVk0SATbsad4B5 hGraQrGAntfEkoHdqdMGo2hL5GWIAhZXBL+GcBqTARYyfn6j3l/V8bxPAWfmAyy5 VYtVZs4Bqcu69LV0Fq2gP/yOxQj20WQNI0momUdpxtAoTb+zmH8iTOxxCxRHmD92 NJshYlryR2gPSaTGiOYWZEtQMTa2k9TKQq1LgzCGs7x2n5LUV2rOp0/sfgxylUQN vllof1fUloUw7id1IigsCA1XtNvflE2LgwT1xzcAzDsBB4SIEio=
    =ijA5
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sven Wick@21:1/5 to All on Sun Mar 17 15:50:01 2024
    Are the new tools replacements or additional?

    Additional

    then ssh-tools-extra would make sense

    That's actually a good suggestion. Thank you

    I don't see why adding a 3rd language
    to the 2 already used makes things 'hard to package'

    The scripts are written with minimal dependency
    and tested with different OSes.
    So they are easy to package.

    Adding the Go ones I have some difficulties myself already:

    - 3rd party dependencies (which are packaged already luckily)
    - I am not yet familiar with packaging Go programs (just managed to create one yesterday)
    - I am not sure if that mixed package should then go to the [1] Go Packaging Team,
    and when, if they are OK with that mix of languages:

    So, yeah maybe after I have worked out these things,
    it is not that difficult anymore
    and actually I would also prefer to keep all in one upstream repo.

    I also don't want to make it any harder to package for [2]others

    [1] https://go-team.pages.debian.net
    [2] https://repology.org/project/ssh-tools/versions

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