Prusaslicer: Name change: packaging question

[ArchangeGabriel]

I’ve seen the recent 2.0.0rc release, and the name change coming with it. As ArchLinux packager, I would like to ask whether our package for the new version should be named prusaslicer or prusa-slicer.

[Salamandar]

As the AUR maintainer, it seems logical for me to rename as prusaslicer.
(BTW, the package will be updated soon, promise !)

[jasontibbitts]

For the Fedora package, I was considering using "prusa-slicer". We prefer lower-case package names (so "PrusaSlicer" would be out) and "prusa-slicer happens to match the name of the executable. "prusaslicer" doesn't seem to match much of anything.

It wouldn't be a bad idea to try to be consistent, though, so a statement from upstream would be nice.

[Salamandar]

You are right, the binary is prusa-slicer and that seems like an inconsistency that should be fixed (or confirmed).

[bubnikv]

We are open to suggestions. As of now, we internally have decided to:

Call the binary prusa-slicer, prusa-slicer.exe, prusa-slicer-console.exe.
@tamasmeszaros is currently working on Debian package in house, which we named prusa-slicer
We have contacted @hyperair , who used to
maintain the Slic3rPE debian package.
We have contacted Miro Hroncok from Redhat to help us with the Fedora
package, but you are guys welcome to help out.

On MacOS, the binary is PrusaSlicer to match the package name, which is
PrusaSlicer.dmg

[ArchangeGabriel]

OK then, I will use the dashed version as I started to do for the new rc PKGBUILD. It seems we all agree on the fact this one is more suited, so let it be so. :)

[jasontibbitts]

Miro ended up linking me in. Looks like we'll go with prusa-slicer for the package name as well.

[Salamandar]

That's deceiving as the project name is "prusaslicer". apt search prusaslicer won't work i guess.

[ArchangeGabriel]

@Salamandar No, the project name is PrusaSlicer, not prusaslicer. But just as many other projects, this cannot translate directly into a package name, because those are generally restricted to lowercase. Then, prusa-slicer makes more sense because those are two words.

[Salamandar]

[troll]
OK, let's rebrand our favorite browser as fire-fox then ;)
[/troll]
OK, I kinda personally don't like it but i'll rename the AUR repo.

[bubnikv]

I personally have not an opinion on it, but it would be nice to do it
consistently across the distributions.

On Mon, May 20, 2019 at 1:12 AM Salamandar [e-mail] wrote:

[troll]
OK, let's rebrand our favorite browser as Fire-Fox then ;)
[/troll]
OK, I kinda personally don't like it but i'll rename the AUR repo.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/prusa3d/PrusaSlicer/issues/2239?email_source=notifications&email_token=ABMPSI7B43ZFB7UVT3TURULPWHNFZA5CNFSM4HNFGHNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVXMWDA#issuecomment-493800204,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABMPSI6ISHGMEN3ATATAOSTPWHNFZANCNFSM4HNFGHNA
.

[hyperair]

I think slic3r-prusa is a nicer name, but given the two choices in https://github.com/prusa3d/PrusaSlicer/issues/2239#issue-444545197, I think prusa-slicer makes more sense. If we have a consensus on this, I'll rename the Debian package to this when the new version comes out.

[bubnikv]

@hyperair The name PrusaSlicer was chosen to differentiate from the upstream slic3r to avoid confusion (mixing pull requests and bug reports between the two repositories). I bet it was a big annoyance to the upstream slic3r guys to receive bug reports and requests on the PrusaSlicer all the time. slic3r-prusa sounds it is still slic3r, it does not help much. The name was chosen to differ enough to be clear that it is a different project. We certainly attribute the slic3r project as the origin.

[vojtechkral]

@jasontibbitts Regarding your comment in the fedora bug #1710526:

In any case, if you do build with the Perl stuff, then you get a Perl module you need to installed, and they haven't renamed its namespace yet. So either we need to patch that or exclude it. I'm going with the latter for now as I don't really know what utility the Perl bindings have currently.

This is the right approach methinks. The Perl bindings _only_ have utility for testing. It's sort of a vestigiality that we haven't yet had the cycles to replace with a non-Perl solution. In the long term, usage or Perl and Perl bindings are to be removed.