search

toltec-dev / toltec

Community-maintained repository of free software for the reMarkable tablet.
https://toltec-dev.org
MIT License
728 stars 60 forks source link

rename generic apps #103

Open raisjn opened 3 years ago

raisjn commented 3 years ago
Eeems commented 3 years ago

I'm not convinced that we really care to do this. Are we saying that no package can have a generic name ever? In my opinion it should really be first come, first served with names, like other repositories do.

matteodelabre commented 3 years ago

I agree with @Eeems on this one. Moreover, we should strive to follow the upstream package name as much as we can to avoid confusing users who are looking for a specific package. So, name changes should be discussed per package at the upstream level IMO.

LinusCDE commented 3 years ago

I guess topic this is based on the discussion in #97. I agree that a package should match the package as close as possible. Though the points in the mentioned PR should also be considered.

Someone making another calculator or minesweeper game would always look like a second class citizen and those are trivial apps, other may do as well.

I didn't think it possible for chess to eventually collide but I was proven wrong as well.

Edit: At least minesweeper clould probably be renamed on the source as well.

raisjn commented 3 years ago

Edit: At least minesweeper clould probably be renamed on the source as well.

i'm thinking freemines or something similar for it

we should strive to follow the upstream package name as much as we can to avoid confusing users who are looking for a specific package

what happens when two packages have same name upstream?

matteodelabre commented 3 years ago

what happens when two packages have same name upstream?

Then we could prefix the two packages with the name of their author, for example. This is something we need to mention in the packaging docs.

raisjn commented 3 years ago

it's weird to me in general that apps can have generic names. i haven't seen such a thing before in Linux repositories, where software often follows a naming scheme based on the library or framework used to build it, like kChess, gChess, GNUChess, pyChess, etc.

if we are really building a repository of software that will last for years, i think this should be paid attention to. we already have the case where people wrote software years ago and we have to stick to their conventions (which are non robust) because they were first on scene

i am not familiar with any written convention around why software is named that way in Linux, but I'm assuming it's because the generic names were grabbed in the 70s and 80s

matteodelabre commented 3 years ago

I fully agree with you @raisjnn, but, if I may reiterate, I think we want to avoid a situation where a package has a name in Toltec that is too far away from its upstream name. Would it be sufficient to add a sentence to https://www.github.com/toltec-dev/toltec/tree/testing/docs/package.md#pkgname asking for authors who submit their packages from now on to avoid choosing a generic name for their project?

raisjn commented 3 years ago

I fully agree with you @raisjnn, but, if I may reiterate, I think we want to avoid a situation where a package has a name in Toltec that is too far away from its upstream name.

if two people choose the name 'foo', one of them will end up with repository/foo or something similar. the people who come looking for foo, will be pointed at the other package with the same name and will inadvertently install it. we will make this situation much more likely to happen by allowing generic names. one possible solution is namespacing all packages (or only ones we think are generic?) so they include a github username or something similar.

Would it be sufficient to add a sentence to https://www.github.com/toltec-dev/toltec/tree/testing/docs/package.md#pkgname asking for authors who submit their packages from now on to avoid choosing a generic name for their project?

i'd still consider banning generic names or advising that if the name is too generic, it might get renamed in the future when there is a collision.

the calculator app is a good example of why i advocate this: the app is super simple and any number of calculators would be more interesting. why do we give preference to one over the other based on time (who reserved the name first), when what would benefit the users is preference of name based on functionality and user experience.

matteodelabre commented 3 years ago

137 adds to the tooling the features needed for renaming packages while providing a seamless transition to end-users.