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