On Sun, Jan 29, 2023 at 12:21 PM Julian Gilbey <
jdg@debian.org> wrote:
On Sun, Jan 29, 2023 at 12:21:29PM +0100, Jonas Smedegaard wrote:
> Quoting Julian Gilbey (2023-01-29 12:03:30)
> > If you would like me to go ahead and work on this, please say.
>
> Sure I would like you to go ahead - why would I not want that?
>
> Sounds like a fun project, and Free, and beneficial to Debian.
Great!
> One thing you might consider is to name the resulting package something
> (similar but) different than fontawesome, to not upset upstream
> developers by hijacking their name for something arguably different.
A good point. I was thinking of creating a GitHub project called
FontAwesome-DFSG, with a README explaining what is it, how it was
created and how it is not endorsed by the FontAwesome "owners". But
I'm not sure what to call the Debian package - it is essentially just
a repackaging of the FontAwesome fonts. Perhaps we could call the
source package fonts-font-awesome-dfsg, and the binary packages
fonts-font-awesome-4.7, fonts-font-awesome-dfsg-5,
fonts-font-awesome-dfsg-6 and fonts-font-awesome-dfsg (for the current
version of the upstream font)?
Please don't take the following info as stop-energy (which it's not), but there is already an active project doing the task of liberating the no-longer-free symbols from Font Awesome, called ForkAwesome:
https://github.com/ForkAwesome/Fork-Awesome ... which has also added a fair number of new glyphs since it was founded (6+ years ago).
It's also already packaged for Debian. I certainly agree that it's a problem that too many other packages pull in FoNT Awesome as a dependency, but the harder work is in persuading maintainers to switch. Convincing them to utilize a package that is already available to them would, I think, be quicker. ForkAwesome certainly hasn't reached 100%, so maybe some people will never make that switch.
But perhaps I misunderstand what you're wanting to do; if you are wanting to do something different than what ForkAwesome already does, like just build a new build script to show it can be done, I may be missing the nuance.
However, If it's just about fixing the dependent packages, having two forks of the original runs some risk of confusing people, and it does kind of divide the community momentum.
Nate
--