Dimitri Fontaine
Dimitri Fontaine
Some el-get recipes have been made that way in the past: build a recipe per file and a top-level recipe with the right set of dependencies... Not ideal, works.
Well that's the advanced setup for manually syncing in between several machines. For the simple use case, you don't have to maintain any list of packages, just `(el-get 'sync)` and...
Oh, you want to use the customize UI for maintaining that part... well, yes I would accept a patch, as I avoid that UI I won't be working on it....
I think having pre- and post- hooks for updating packages is a good idea, and a new boolean property `:reload` defaults true is a good idea too. I don't much...
Well I prefer `:reload`, but he who does the work gets to choose :)
Fallback mechanism already kind of exists, you can have several recipes dirs. We could have also a blacklist of protocols to refuse using. Given those two features, we would have...
Not that few. The type and URL both change entirely. Also when going from, say, git to http-tar, you can expect the build commands to be different (autoconf already run...
No. There's no good reason to use git:// over http(s)://, so let's just change the existing recipes. What I'm talking about is having something more general here. We've already seen...
I think you're right and we should be hijacking `package-archives` in the `package.rcp` recipe. Will accept a patch for that.
Yeah that was a typo.