Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

review what darktable default supported feature should be #15803

Open
TurboGit opened this issue Dec 1, 2023 · 7 comments
Open

review what darktable default supported feature should be #15803

TurboGit opened this issue Dec 1, 2023 · 7 comments

Comments

@TurboGit
Copy link
Member

TurboGit commented Dec 1, 2023

Is your feature request related to a problem? Please describe.

Often people install a version from the Linux distribution and found that such or such feature are missing (like CUPS, HEIF support...)

Describe the solution you'd like

Have what we want to be a proper darktable config be the default.

What about making more packages as required and have an option to disable them instead of the opposite?

This would avoid packagers to build with missing feature silently. If a given package is not available on the target version then one will have to disable explicitly the support.

How does that sound?

EDIT: We had many issue like this, last one:
https://discuss.pixls.us/t/cr3-and-heif-support/32800/37

@kmilos
Copy link
Contributor

kmilos commented Dec 1, 2023

Although this is good from the perspective of making packagers more aware, I don't see how it can help manage user expectations?

@TurboGit
Copy link
Member Author

TurboGit commented Dec 1, 2023

To me the missing features are just an overlook from packagers as the build silently skip missing libs, so it will help manage user expectations by most probably engage the packager to support more features. Or did I missed your point?

@kmilos
Copy link
Contributor

kmilos commented Dec 1, 2023

Silent or not, some feature will be missing (simply not available for a particular distro version), and that's what the user cares about. I don't think the users understand (or care) why it's missing, nor that they should reach out to the distro packagers instead of here or discuss.pixls.us.

Edit: but sure, maybe we're able to force some other limited subset of features to be enabled sooner this way.

@parafin
Copy link
Member

parafin commented Dec 1, 2023

Silently disabling features is bad for packagers, since it’s very easy to miss that some feature is no longer functioning due to changes in dependencies. It’s especially painful for rolling-release distributions. Build options should be on/off with no automatic behaviour (or auto being a third option). What to choose as default is a separate question. Perhaps off is actually better for newly added features, since it won’t break existing packaging scripts then.

@TurboGit
Copy link
Member Author

TurboGit commented Dec 1, 2023

Silently disabling features is bad for packagers, since it’s very easy to miss that some feature is no longer functioning due to changes in dependencies.

That's why I want to avoid that in my proposal.

@kmilos
Copy link
Contributor

kmilos commented Dec 5, 2023

Ok, I've made a first stab at it, let me know what you think. The next question is what should be ON by default, as I guess this will start failing for a lot of people OOTB.

I haven't covered a couple that look a bit more complicated (COLORD and LUA I think).

Copy link

github-actions bot commented Feb 4, 2024

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants