add xfburn package

[ryanfortner]

Closes #1894

[theofficialgman]

@Botspot would you might adding additional "rules" to the rubric specifically regarding package apps. #185

I have said before that I don't like package apps and don't feel like they really fit pi-apps but that isn't the matter of discussion here (I can just disable them with the settings toggle which is enough for me).

What I would like clarified is what type of package apps should be eligible/included in pi-apps. I feel like we are reaching the point where package apps are becoming a significant portion of the app list and rules for their inclusion should be listed.

[Botspot]

@Botspot would you might adding additional "rules" to the rubric specifically regarding package apps. #185

I have said before that I don't like package apps and don't feel like they really fit pi-apps but that isn't the matter of discussion here (I can just disable them with the settings toggle which is enough for me).

What I would like clarified is what type of package apps should be eligible/included in pi-apps. I feel like we are reaching the point where package apps are becoming a significant portion of the app list and rules for their inclusion should be listed.

A bit of background:
I never intended for Pi-Apps to include apt packages. But I also never intended it to be a primary installation method for some users.
What ended up happening was that apps available on apt began having a disadvantage.
If a GUI user wants to install an image editor from a curated list of apps (which is what Pi-Apps has become), it would be a shame to only include non-apt apps, while excluding potentially better options just because they were from apt.

TL;DR The purpose of package-apps is to avoid having major holes in the app selection.

There is definitely a potential for this package-app feature to be taken too far. @theofficialgman, if you have any particular package-apps in mind that don't seem to fit, by all means let me know.

[Crilum]

The purpose of Pi-Apps is definitely not an Apt GUI..

[theofficialgman]

What ended up happening was that apps available on apt began having a disadvantage. If a GUI user wants to install an image editor from a curated list of apps (which is what Pi-Apps has become), it would be a shame to only include non-apt apps, while excluding potentially better options just because they were from apt.

I like this explanation, it makes sense. Given this, do you think it would be a good idea for our "rules" then to say that package apps should only be included if there is already a similar alternative for that package already included in pi-apps?

under this "rule" the xfburn package app would be fine to include because there is similar non-package app software already pi-apps (USBImager)

[Crilum]

there is already a similar alternative for that package already included in pi-apps?

is or isn't?

[theofficialgman]

is or isn't?

is. I think we should only include a package app IF there is already an install(32/64) type software for that in pi-apps. basically, no new random software from package apps that has no pi-apps unique (install32/64) alternative

[Botspot]

I like this explanation, it makes sense. Given this, do you think it would be a good idea for our "rules" then to say that package apps should only be included if there is already a similar alternative for that package already included in pi-apps?

This sounds reasonable to me, though it might make for some silly situations down the road.
For example, a potential app-submitter may try to add a script app for the sole purpose of adding a package-app afterwards.
Or, the app-submitter will make a script-app to install a slightly newer version of an already available apt package, "just because" it's allowed. But I guess this one has already happened a few times. 😂