There should be `lunar enforce` that always answer 'yes' for module X #24

Closed
Phr33d0m opened this Issue Aug 31, 2012 · 8 comments

Projects

None yet

4 participants

@Phr33d0m

Okay, as we have discussed in #lunar , the same way lunar exile <#> exists (that always answers 'no' for module #), there should be a lunar enforce <#> that always answer 'yes' for module #.

@cavalier38 cavalier38 added a commit to cavalier38/lunar that referenced this issue Aug 31, 2012
@cavalier38 cavalier38 Added lunar enforce
enforced modules are stored in LUNAR_ENFORCE in the local config file
fixes #24
fe6d054
@cavalier38
Member

If I should make this a true pull request, please let me know. If you know how to attach this commit as pull request, that would be even better. Since there are more commits pending to this

@Ratler
Member
Ratler commented Sep 1, 2012

cavalier38 commented

If I should make this a true pull request, please let me know. If you know how to attach this commit as pull request, > that would be even better. Since there are more commits pending to this

You can't do that easily. Either you need to use one of the github wrappers for git, or you will have to attach a pullrequest to an issue using curl to post a specially crafted JSON blob to github :)

@cavalier38
Member

I tried to attach a pull-request with curl. but I get "resource": "PullRequest", "code": "unauthorized", "field": "issue". Should I just create a new pull-request instead?

@sofar
Member
sofar commented Nov 5, 2012

I don't like that we're creating more config options. We implemented "held" much nicer.

Can we rewrite this so that /var/state/lunar/packages allows the following entries in the state field:

:installed:
:exiled:
:installed+enforced:
:installed+held:
:installed+held+enforced:

That would make this a lot more consistent, extensible in the future and probably a bit cleaner.

@cavalier38
Member

The reason I didn't put it in there was, that we only had :exiled: :installed: and :held: but with these combinations this can be fixed. Just to be complete also is :enforced: without installed.
This would have a big impact as there are locations which check for :installed: and not with module_installed.
I'll create new branch to start working on this idea.

@cavalier38
Member

I looked into this a bit further. And the change is not really trivial. add_module {un,}(hold,exile,enforce}_module should be handled differently. maybe use some add_module_status remove_module_status routines. The checks for :install: and :held: are no problem to fix.
Also there is backwards compatibility. Now, if you a module is :held: it implies :installed: that means that something like remove_module_status should handle this exception. Or lin lunar should convert this. Note: To go back you first need to lunar unhold $(lvu held) lunar unenforce $(lvu enforced).
Before I continue on this path. Is this worth the effort?

@cavalier38 cavalier38 added a commit to cavalier38/lunar that referenced this issue Nov 11, 2012
@cavalier38 cavalier38 Added lunar enforce
This includes changing the state to state flags separated with + in the
MODULE_STATUS files
Issue #24
747132d
@cavalier38
Member

This new branch implements enforced using state flags. According to the description in the last few posts.

@sofar
Member
sofar commented Nov 18, 2012

+like.

Want to send a pull request?

@Ratler Ratler closed this May 30, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment