On Tue, 20 Oct 2015 00:47:49 -0700 Daniel Campbell <z...@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 10/17/2015 05:52 AM, Ulrich Mueller wrote: > >>>>>> On Sat, 17 Oct 2015, hasufell wrote: > > > >>> 2. eapply_user really belongs in the PM, especially if it's run > >>> by default. And it needs patch applying function. And if we > >>> have to implement patch applying function anyway, we may as > >>> well make it public to avoid unnecessary duplication. > > > >> Unreliable. The ebuild may define its own src_prepare function > > > > That eapply_user is called can be enforced by repoman, or by a QA > > warning. > > > >> or the PM might define eapply_user as a no-op, which is valid as > >> per PMS. > > > > Sure, it is implementation defined. Otherwise PMS would have to > > specify all the details, e.g. where does the package manager look > > for user-supplied patches and how are patch directories organised. > > > > Ulrich > > > I'm not sure I follow. What's wrong with supporting env vars like > EPATCH_PATH or EPATCH_DIRS, with whatever 'sane default' that the PM > in question deems proper? Configuration would be simple and unify any > manager that adheres to the spec. If it's implementation-defined, then > each package manager would look in a possibly different directory. If > we're outlining a spec, imo it would be best to at least establish a > common directory so PM authors can rely on it confidently and help > avoid user issues. > > If I'm missing some detail that doesn't make my idea any good, please > tell me. It doesn't seem like trouble from where I'm looking. I think the idea behind PMS is that the gentoo portage tree (or ebuilds in general) obeys some rules so that ebuild behavior doesn't depend on the portage version you're using and is the same with alternative package managers. I don't think its scope is to define a common way to configure package managers. Not that the idea is bad, but it'd be better done by having the three PM agree on some common ground here.
