public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Alexis Ballier <aballier@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review
Date: Tue, 20 Oct 2015 10:00:10 +0200	[thread overview]
Message-ID: <20151020100010.537f853a@gentoo.org> (raw)
In-Reply-To: <5625F1A5.4070403@gentoo.org>

On Tue, 20 Oct 2015 00:47:49 -0700
Daniel Campbell <zlg@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.


  reply	other threads:[~2015-10-20  8:00 UTC|newest]

Thread overview: 90+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <22049.17676.1822.986579@a1i15.kph.uni-mainz.de>
2015-10-17 12:19 ` [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review Jason A. Donenfeld
2015-10-17 12:21   ` Jason A. Donenfeld
2015-10-17 12:24   ` Michał Górny
2015-10-17 12:28     ` hasufell
2015-10-17 12:52       ` Ulrich Mueller
2015-10-17 12:56         ` hasufell
2015-10-17 13:07           ` Ulrich Mueller
2015-10-17 15:22             ` hasufell
2015-10-17 16:40               ` Alexis Ballier
2015-10-17 22:16         ` Rich Freeman
2015-10-18  8:33           ` Alexis Ballier
2015-10-18  9:54           ` Ulrich Mueller
2015-10-18  9:56             ` Alexis Ballier
2015-10-18 10:13             ` Michał Górny
2015-10-18 10:17               ` Ulrich Mueller
2015-10-18 10:49                 ` Rich Freeman
2015-10-19  7:12                 ` Alexis Ballier
2015-10-19  7:22                   ` Anthony G. Basile
2015-10-19  7:28                     ` Alexis Ballier
2015-10-19  8:25                     ` Ulrich Mueller
2015-10-19  8:31                       ` Alexis Ballier
2015-10-19  7:58                   ` Michał Górny
2015-10-19  8:04                     ` Alexis Ballier
2015-10-19  8:09                       ` Michał Górny
2015-10-19  8:17                         ` Alexis Ballier
2015-10-19  8:07                     ` Anthony G. Basile
2015-10-19 22:07                     ` Andreas K. Huettel
2015-10-19 12:38                   ` Rich Freeman
2015-10-19 13:34                     ` Alexis Ballier
2015-10-19 13:51                       ` Rich Freeman
2015-10-19 14:21                         ` Alexis Ballier
2015-10-19 17:17                           ` Rich Freeman
2015-10-19 18:28                             ` Alexis Ballier
2015-10-19 19:49                               ` Rich Freeman
2015-10-20  7:51                                 ` Alexis Ballier
2015-10-20  8:57                                   ` Rich Freeman
2015-10-20  9:22                                     ` Alexis Ballier
2015-10-20 10:00                                       ` Rich Freeman
2015-10-20 10:25                                         ` Alexis Ballier
2015-10-21  1:24                                           ` Duncan
2015-10-21  7:29                                             ` Alexis Ballier
2015-10-18 10:36             ` Alexis Ballier
2015-10-20  7:47         ` Daniel Campbell
2015-10-20  8:00           ` Alexis Ballier [this message]
2015-10-17 12:42     ` Ulrich Mueller
2015-10-17 12:25   ` hasufell
2015-10-17 12:38     ` Rich Freeman
2015-10-17 12:49       ` hasufell
2015-10-17 12:56         ` Rich Freeman
2015-10-17 13:02           ` hasufell
2015-10-17 13:47         ` Alexis Ballier
2015-10-17 15:00           ` hasufell
2015-10-17 16:07             ` Anthony G. Basile
2015-10-17 16:35               ` Alexis Ballier
2015-10-17 18:03         ` Ciaran McCreesh
2015-10-18 11:37           ` hasufell
2015-10-18 11:43             ` Rich Freeman
2015-10-18 12:05               ` hasufell
2015-10-18 12:24                 ` Rich Freeman
2015-10-17 12:51       ` Michał Górny
2015-10-17 19:15         ` Rich Freeman
2015-10-17 20:08 ` Alexis Ballier
2015-10-17 20:47   ` Ulrich Mueller
2015-10-18  8:31     ` Alexis Ballier
2015-10-18  8:48       ` Michał Górny
2015-10-18  9:23         ` Alexis Ballier
2015-10-18 10:07           ` Michał Górny
2015-10-18 10:34             ` Alexis Ballier
2015-10-18 11:54           ` Andreas K. Huettel
2015-10-18 11:57             ` Alexis Ballier
2015-10-18 12:44       ` Ciaran McCreesh
2015-10-18 13:01         ` Rich Freeman
2015-10-18 18:00         ` Alexis Ballier
2015-10-18 18:06           ` Ciaran McCreesh
2015-10-18 18:19             ` Alexis Ballier
2015-10-18 18:36               ` Ciaran McCreesh
2015-10-18 19:20                 ` Alexis Ballier
2015-10-17 21:24   ` Michał Górny
2015-10-18  8:47     ` Alexis Ballier
2015-10-18  9:01       ` Michał Górny
2015-10-18  9:34         ` Alexis Ballier
2015-10-18 10:09           ` Michał Górny
2015-10-18 10:31             ` Alexis Ballier
2015-10-20 18:55 ` [gentoo-dev] utilizing BASH_COMPAT to smooth upgrades Mike Frysinger
2015-10-20 22:03   ` Ulrich Mueller
2015-10-20 22:51     ` Mike Frysinger
2015-10-21  7:34       ` [gentoo-dev] [PATCH] Recommend setting the bash compatibility level. (was: Re: utilizing BASH_COMPAT to smooth upgrades) Ulrich Mueller
2015-10-22 13:55         ` [gentoo-dev] " Mike Frysinger
2015-10-22 15:00           ` Ulrich Mueller
2015-10-22 15:21             ` Mike Frysinger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151020100010.537f853a@gentoo.org \
    --to=aballier@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox