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

Declarative configuration #35

Open
nponeccop opened this issue Dec 27, 2014 · 2 comments
Open

Declarative configuration #35

nponeccop opened this issue Dec 27, 2014 · 2 comments

Comments

@nponeccop
Copy link

I propose to have configuration files to substantially reduce the need for patches, as patches are brittle. As can be seen from recent GHC update, version updates require recommitting of patches as they contain version numbers.

Patches are a good idea because they are universal and allow any type of modification. However, it turns out that most often the only changes needed are changes to the list of dependencies detected by cblrepo. So I propose someting like patches/<pkgname>.override with

depends=+foo -bar +baz

So this information is applied internally by cblrepo to its detected list of dependencies before generation of PKGBUILD and it doesn't contain version numbers so there is no need to maintain it on every update. Then patching proceeds as usual.

The .override files are technically not patches, but putting them in patches/ lets a user to uniformly inspect/remove all overrides by ls patches/<pkgname>.*, rm, vim -p etc. And the config can be extended to support overrides other from depends if we ever decide so.

@magthe
Copy link
Contributor

magthe commented Dec 28, 2014

Am I to understand this is an alternative to #32?

@nponeccop
Copy link
Author

#32 will reduce the number of cases where we need manual patching. But I think it will still fail sometimes (for example for non-library dependencies). This #35 feature will make maintenance of patches easier in many cases. I understand the two features as independent improvements.

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

No branches or pull requests

2 participants