[opam-devel] current opam-repository policy : who can modify a package description

Daniel Bünzli daniel.buenzli at erratique.ch
Mon Feb 22 15:19:27 GMT 2016


Le lundi, 22 février 2016 à 15:48, Fabrice Le Fessant a écrit :
> and that version would automatically add an ocamlbuild dependency to every package, except if it has an "ocamlbuild: false" header (or something like that). I am not saying it is the best solution, but changing 4000 packages seem even worse for me. I presume that, most of the time, it is possible to fix such problems in opam rather than in opam-repository.

Adding magic in opam is certainly the worst solution to these kind of problems: let's add ad-hoc layers of obscurity and special cases to the system.

> Package maintainers, as in Debian, are not the authors, they are the people who decide to take responsibility for making a package public on OPAM.

The opam-repository is not debian, it's a package repository for and by developers. What you describe here doesn't reflect the reality which is, in the current state, that most packagers are the package developer themselves.
  
> On the contrary, repo maintainers are only in charge of maintaining the global consistency of the repository, deciding when there is a conflict between package maintainers, and so on. The whole point of this discussion is to prevent repo maintainers from acting as package maintainers, so this distinction is important !
This is a little bit contradictory. If maintainers have to maintain the global consistency of the repository they do have from time to time to act on the package themselves, if only to be able to do so in a timely manner when everything breaks in the repo (which fortunately rarely happened so far).   

Frankly, I think you are blowing things a little bit out of proportions here. It seems that as it stand the repository has been working quite well with minimal friction under the current operating structure. I don't say it should never change in the future but you seem to be only one to be complaining with arguments that seem a little bit out of touch with the reality of the opam-repository.

Best,  

Daniel

 


More information about the opam-devel mailing list