[gentoo-dev] Re: gnatbuild.eclass refactoring: new/transitory eclass?

[Duncan]

Alexandre Rostovtsev posted on Fri, 04 Sep 2015 10:05:31 -0400 as
excerpted:

> On Thu, 2015-09-03 at 16:00 +0200, George Shapovalov wrote:
>> 2. Is there some standard naming scheme? Should the new eclass be
>> called, say,
>> gnatbuild2.eclass or gnatbuild-ng.eclass? Of course this only matters
>> if old eclass is there to stay. If not I'll just call the transitory
>> eclass something like gnatbuild-refactor.eclass for the duration of its
>> existence..
> 
> I suggest gnatbuild-r1.eclass, that seems to be the most widely used
> eclass versioning pattern. Some examples:
> 
> bash-completion.eclass → bash-completion-r1.eclass (2011)
> distutils.eclass → distutils-r1.eclass (2012)
> emboss.eclass → emboss-r1.eclass (2015)
> git.eclass → git-2.eclass (2011) → git-r3.eclass (2013)
> myspell.eclass → myspell-r2.eclass (2012)
> office-ext.eclass → office-ext-r1.eclass (2013)
> python.eclass → python-r1.eclass (2012)
> qt4.eclass → qt4-r2.eclass (2009)
> 
> Other patterns:
> 
> java-utils.eclass → java-utils-2.eclass (2006)
> mysql.eclass → mysql-v2.eclass (2011)
> ruby.eclass → ruby-ng.eclass (2009)

Just to add...

As the folks doing the git eclasses found out, bare generation numbers 
are all too easily confused with upstream version numbers -- git-2.eclass, 
is that for use with git-2*?  

Given that gentooers are already familiar with the -rN identifier from 
ebuilds and know that there it unambiguously indicates a gentoo revision, 
as opposed to upstream, the same idea was eventually borrowed for eclasses 
identifiers -- git-r3.eclass unambiguously indicates what git-2.eclass 
didn't, that it's the third /gentoo/ generation of git eclass, *not* just 
for /upstream/ git-v3 (when there is one).  (Xref eclasses such as qt4, 
kde4, qt5... where the number indicates upstream version.)

So -rN has become the standard gentoo-generation identifier for eclasses, 
meaning much the same thing as it does when used for ebuilds.  If you'll 
note, the other listed patterns are from 2011 or earlier, when the 
git-2.eclass experience proved its name a confusing mistake and 
effectively catalyzed the standardization around the -rN pattern that  
was apparently (based on the above dates) first used with qt4-r2.eclass 
in 2009.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] [PATCH] eutils.eclass: Allow to configure base patch location for epatch_user

[Julian Ospald]

This is particularly useful for people who run alternative
package managers and want to control their configuration.

Github-PR: https://github.com/gentoo/gentoo/pull/69
---
 eclass/eutils.eclass | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
index fecd375..be65960 100644
--- a/eclass/eutils.eclass
+++ b/eclass/eutils.eclass
@@ -350,6 +350,12 @@ EPATCH_FORCE="no"
 # List of patches not to apply. Note this is only file names,
 # and not the full path.  Globs accepted.
 
+# @VARIABLE: EPATCH_USER_SOURCE
+# @DESCRIPTION:
+# Location for user patches, see the epatch_user function.
+# Should be set by the user. Don't set this in ebuilds.
+: ${EPATCH_USER_SOURCE:=${PORTAGE_CONFIGROOT%/}/etc/portage/patches}
+
 # @FUNCTION: epatch
 # @USAGE: [options] [patches] [dirs of patches]
 # @DESCRIPTION:
@@ -697,11 +703,11 @@ epatch_user() {
[[ -e ${applied} ]] && return 2
 
# don't clobber any EPATCH vars that the parent might want
-   local EPATCH_SOURCE check 
base=${PORTAGE_CONFIGROOT%/}/etc/portage/patches
+   local EPATCH_SOURCE check
for check in ${CATEGORY}/{${P}-${PR},${P},${PN}}{,:${SLOT}}; do
-   EPATCH_SOURCE=${base}/${CTARGET}/${check}
-   [[ -r ${EPATCH_SOURCE} ]] || 
EPATCH_SOURCE=${base}/${CHOST}/${check}
-   [[ -r ${EPATCH_SOURCE} ]] || EPATCH_SOURCE=${base}/${check}
+   EPATCH_SOURCE=${EPATCH_USER_SOURCE}/${CTARGET}/${check}
+   [[ -r ${EPATCH_SOURCE} ]] || 
EPATCH_SOURCE=${EPATCH_USER_SOURCE}/${CHOST}/${check}
+   [[ -r ${EPATCH_SOURCE} ]] || 
EPATCH_SOURCE=${EPATCH_USER_SOURCE}/${check}
if [[ -d ${EPATCH_SOURCE} ]] ; then
EPATCH_SOURCE=${EPATCH_SOURCE} \
EPATCH_SUFFIX="patch" \
-- 
2.5.1

Re: [gentoo-portage-dev] [PATCH v2] repoman: ignore unadded files when possible (bug 559636)

[Brian Dolbec]

On Sat, 5 Sep 2015 15:47:50 -0400
Mike Gilbert  wrote:

> On Sat, Sep 5, 2015 at 12:16 PM, Brian Dolbec 
> wrote:
> > On Sat,  5 Sep 2015 07:31:27 -0700
> > Zac Medico  wrote:
> >
> >> Unadded files that are excluded from the Manifest are safe to
> >> ignore.
> >>
> >> X-Gentoo-Bug: 559636
> >> X-Gentoo-Bug-url: https://bugs.gentoo.org/show_bug.cgi?id=559636
> >> ---
> >> [PATCH v2] fixes it to properly check the find_invalid_path_char
> >> return value bin/repoman | 6 +-
> >>  1 file changed, 5 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/bin/repoman b/bin/repoman
> >> index 1ba7841..2c42c2d 100755
> >> --- a/bin/repoman
> >> +++ b/bin/repoman
> >> @@ -2570,7 +2570,11 @@ else:
> >>   if myunadded:
> >>   for x in range(len(myunadded)-1, -1, -1):
> >>   xs = myunadded[x].split("/")
> >> - if xs[-1] == "files":
> >> + if
> >> repo_config.find_invalid_path_char(myunadded[x]) != -1:
> >> + # The Manifest excludes this file,
> >> + # so it's safe to ignore.
> >> + del myunadded[x]
> >> + elif xs[-1] == "files":
> >>   print("!!! files dir is not added!
> >> Please correct this.") sys.exit(-1)
> >>   elif xs[-1] == "Manifest":
> >
> > uhg :( not another patch to "old" repoman code.
> >
> > I really want to get the rewrite code into portage master BEFORE any
> > more patches, or changes are applied.  There has been enough
> > changes, that even the simplest small change can make it a rebase
> > nightmare.
> >
> > At this point, I will only accept patches on the rewrite
> 
> The rewrite has been sitting there for the better part of a year. Get
> on with the merging already!
> 
> Also, please see https://bugs.gentoo.org/show_bug.cgi?id=557864, which
> is the only regression I have found so far.
> 

Doh! I replied too soon, that is the very bug this patch was for, but
to the old code...

I'll port it to the rewrite then.

-- 
Brian Dolbec 

[gentoo-dev] [RFC] dev-rust category

[Jauhien Piatlicki]

Hi,

I have plans to split ?/cargo-bin [1] package from the dev-lang/rust-bin
one. We have already dev-rust/cargo package in the rust overlay[2].

It would be logical to have dev-rust/cargo-bin package then. But there
is a problem: it will be the only package in this category in the tree
and it is not welcome to have categories with small number of packages.
Other rust stuff will appear, but later (with no estimate), as a number
of problems with packaging source rust packages should be solved before
(afaik upstream also has plans to improve rust packaging). The same
about moving source cargo to the tree.

So what is better, create dev-util/cargo-bin package and later, when
rust infrastructure grows, move it to the dev-rust category or create
new category now?

[1] https://crates.io/
[2] https://github.com/Heather/gentoo-rust

--
Jauhien



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH v2] repoman: ignore unadded files when possible (bug 559636)

[Mike Gilbert]

On Sat, Sep 5, 2015 at 12:16 PM, Brian Dolbec  wrote:
> On Sat,  5 Sep 2015 07:31:27 -0700
> Zac Medico  wrote:
>
>> Unadded files that are excluded from the Manifest are safe to ignore.
>>
>> X-Gentoo-Bug: 559636
>> X-Gentoo-Bug-url: https://bugs.gentoo.org/show_bug.cgi?id=559636
>> ---
>> [PATCH v2] fixes it to properly check the find_invalid_path_char
>> return value bin/repoman | 6 +-
>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/bin/repoman b/bin/repoman
>> index 1ba7841..2c42c2d 100755
>> --- a/bin/repoman
>> +++ b/bin/repoman
>> @@ -2570,7 +2570,11 @@ else:
>>   if myunadded:
>>   for x in range(len(myunadded)-1, -1, -1):
>>   xs = myunadded[x].split("/")
>> - if xs[-1] == "files":
>> + if
>> repo_config.find_invalid_path_char(myunadded[x]) != -1:
>> + # The Manifest excludes this file,
>> + # so it's safe to ignore.
>> + del myunadded[x]
>> + elif xs[-1] == "files":
>>   print("!!! files dir is not added!
>> Please correct this.") sys.exit(-1)
>>   elif xs[-1] == "Manifest":
>
> uhg :( not another patch to "old" repoman code.
>
> I really want to get the rewrite code into portage master BEFORE any
> more patches, or changes are applied.  There has been enough changes,
> that even the simplest small change can make it a rebase nightmare.
>
> At this point, I will only accept patches on the rewrite

The rewrite has been sitting there for the better part of a year. Get
on with the merging already!

Also, please see https://bugs.gentoo.org/show_bug.cgi?id=557864, which
is the only regression I have found so far.

Re: [gentoo-portage-dev] [PATCH v2] repoman: ignore unadded files when possible (bug 559636)

[Brian Dolbec]

On Sat, 5 Sep 2015 15:47:50 -0400
Mike Gilbert  wrote:

> On Sat, Sep 5, 2015 at 12:16 PM, Brian Dolbec 
> wrote:
> > On Sat,  5 Sep 2015 07:31:27 -0700
> > Zac Medico  wrote:
> >
> >> Unadded files that are excluded from the Manifest are safe to
> >> ignore.
> >>
> >> X-Gentoo-Bug: 559636
> >> X-Gentoo-Bug-url: https://bugs.gentoo.org/show_bug.cgi?id=559636
> >> ---
> >> [PATCH v2] fixes it to properly check the find_invalid_path_char
> >> return value bin/repoman | 6 +-
> >>  1 file changed, 5 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/bin/repoman b/bin/repoman
> >> index 1ba7841..2c42c2d 100755
> >> --- a/bin/repoman
> >> +++ b/bin/repoman
> >> @@ -2570,7 +2570,11 @@ else:
> >>   if myunadded:
> >>   for x in range(len(myunadded)-1, -1, -1):
> >>   xs = myunadded[x].split("/")
> >> - if xs[-1] == "files":
> >> + if
> >> repo_config.find_invalid_path_char(myunadded[x]) != -1:
> >> + # The Manifest excludes this file,
> >> + # so it's safe to ignore.
> >> + del myunadded[x]
> >> + elif xs[-1] == "files":
> >>   print("!!! files dir is not added!
> >> Please correct this.") sys.exit(-1)
> >>   elif xs[-1] == "Manifest":
> >
> > uhg :( not another patch to "old" repoman code.
> >
> > I really want to get the rewrite code into portage master BEFORE any
> > more patches, or changes are applied.  There has been enough
> > changes, that even the simplest small change can make it a rebase
> > nightmare.
> >
> > At this point, I will only accept patches on the rewrite
> 
> The rewrite has been sitting there for the better part of a year. Get
> on with the merging already!
> 
> Also, please see https://bugs.gentoo.org/show_bug.cgi?id=557864, which
> is the only regression I have found so far.
> 

I've been busy with too many new things to get them all done.

I had thought I would have it merged already, but got distracted with
my new (used) dual xeon workstation. trying to get it running to take
over from my old core2 system.  Plus a few other things...

I have the new compression code ready for catalyst now too in the
pending branch for some final testing before merge.

I'll see if I can track down that regression, and submit it for final
review before merge.

Then we can patch it and progress with the rewrite at the same time.

-- 
Brian Dolbec 

Re: [gentoo-dev] [RFC] dev-rust category

[Matthew Thode]

On 09/05/2015 02:21 PM, Jauhien Piatlicki wrote:
> Hi,
> 
> I have plans to split ?/cargo-bin [1] package from the dev-lang/rust-bin
> one. We have already dev-rust/cargo package in the rust overlay[2].
> 
> It would be logical to have dev-rust/cargo-bin package then. But there
> is a problem: it will be the only package in this category in the tree
> and it is not welcome to have categories with small number of packages.
> Other rust stuff will appear, but later (with no estimate), as a number
> of problems with packaging source rust packages should be solved before
> (afaik upstream also has plans to improve rust packaging). The same
> about moving source cargo to the tree.
> 
> So what is better, create dev-util/cargo-bin package and later, when
> rust infrastructure grows, move it to the dev-rust category or create
> new category now?
> 
> [1] https://crates.io/
> [2] https://github.com/Heather/gentoo-rust
> 
> --
> Jauhien
> 

I think cargo should probably go in dev-util with other rust libraries
and programs going into dev-rust as needed, but that's just me :D

-- 
Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] dev-rust category

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/05/2015 01:04 PM, Matthew Thode wrote:
> On 09/05/2015 02:21 PM, Jauhien Piatlicki wrote:
>> Hi,
>> 
>> I have plans to split ?/cargo-bin [1] package from the
>> dev-lang/rust-bin one. We have already dev-rust/cargo package in
>> the rust overlay[2].
>> 
>> It would be logical to have dev-rust/cargo-bin package then. But
>> there is a problem: it will be the only package in this category
>> in the tree and it is not welcome to have categories with small
>> number of packages. Other rust stuff will appear, but later (with
>> no estimate), as a number of problems with packaging source rust
>> packages should be solved before (afaik upstream also has plans
>> to improve rust packaging). The same about moving source cargo to
>> the tree.
>> 
>> So what is better, create dev-util/cargo-bin package and later,
>> when rust infrastructure grows, move it to the dev-rust category
>> or create new category now?
>> 
>> [1] https://crates.io/ [2]
>> https://github.com/Heather/gentoo-rust
>> 
>> -- Jauhien
>> 
> 
> I think cargo should probably go in dev-util with other rust
> libraries and programs going into dev-rust as needed, but that's
> just me :D

Agreed. dev-util until it grows in size (isn't the recommendation
5-10+ pkgs?), then dev-rust. Despite the package moves being somewhat
cumbersome, it makes more sense to do it once it's clear Rust has an
ecosystem going rather than catch stragglers in its infancy.

For platform-specific things like compilers, dev-lang/ may be a better
candidate.

Just my 2¢.


- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJV610xAAoJEAEkDpRQOeFw/RwQAJZfazVJ5hXgLUKDnsLS4fEX
qVtUoacuC5CCXrcfqFcH5joYdhRAjFkM1AsS1zmGac7Ew3rLBuZZeZmOEror7NL9
LaNqWkLNGNjOWmg+R3fE+LpsiBfl2iD4taCdlZ9W4Qv2gSV2gsWhHRgCM3n6MtqB
hg4y9INeUauEkwKiTqTr8ZBoqSmo49t+isbytQQfGS22SLZXVK7iQny7w/NR7vr6
dVgbURa/+fLOaPGd3+O66zj1CD40bpohLmcgbXELkOfe5x+P7ngAUq0SBqytzI7b
nex6Jx+7ioQtyl8DEg22M16EIuF7t7/ySetI0Dd2SgurapzxAykIJcgrU8FvBxOi
k5buTcqSXcf2GQqqDQJyFFUIqf4BT9H5cM+7MkDNiQFqck8UkA8uVMSbWGw5E+Po
/6zfaXkBBOZlt6eH55XFdCGouSdAD/Pu7bNQ+GEswRWqSs3CQ9SkibRxr/d8rV85
1uipXSH8wcVPgOWoM2gIhBydGP6nqBjS4DHiPF9HL5felAdErTmk6tdnAxAkfey7
DVUdmMG5rjaOorpFHYvujTufUO3BYDXf0eA8ImR6jwok4Sfm2UR0xfReBGmNpNz6
lDa3kC3q0x5iU9vBv3NvhAH/mG/J9lE2BAxyS0F00l/4ykf2bMKSjqfrLLIpTUcb
bW5RmPOk9vVc7GSKSdox
=cMLX
-END PGP SIGNATURE-

Re: [gentoo-portage-dev] [PATCH v2] repoman: ignore unadded files when possible (bug 559636)

[Brian Dolbec]

On Sat, 5 Sep 2015 12:50:22 -0700
Zac Medico  wrote:

> On 09/05/2015 09:18 AM, Zac Medico wrote:
> > On 09/05/2015 09:16 AM, Brian Dolbec wrote:
> >> On Sat,  5 Sep 2015 07:31:27 -0700
> >> Zac Medico  wrote:
> >>
> >>> Unadded files that are excluded from the Manifest are safe to
> >>> ignore.
> >>>
> >>> X-Gentoo-Bug: 559636
> >>> X-Gentoo-Bug-url: https://bugs.gentoo.org/show_bug.cgi?id=559636
> >>> ---
> >>> [PATCH v2] fixes it to properly check the find_invalid_path_char
> >>> return value bin/repoman | 6 +-
> >>>  1 file changed, 5 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/bin/repoman b/bin/repoman
> >>> index 1ba7841..2c42c2d 100755
> >>> --- a/bin/repoman
> >>> +++ b/bin/repoman
> >>> @@ -2570,7 +2570,11 @@ else:
> >>>   if myunadded:
> >>>   for x in range(len(myunadded)-1, -1, -1):
> >>>   xs = myunadded[x].split("/")
> >>> - if xs[-1] == "files":
> >>> + if
> >>> repo_config.find_invalid_path_char(myunadded[x]) != -1:
> >>> + # The Manifest excludes this
> >>> file,
> >>> + # so it's safe to ignore.
> >>> + del myunadded[x]
> >>> + elif xs[-1] == "files":
> >>>   print("!!! files dir is not
> >>> added! Please correct this.") sys.exit(-1)
> >>>   elif xs[-1] == "Manifest":
> >>
> >> uhg :( not another patch to "old" repoman code.
> >>
> >> I really want to get the rewrite code into portage master BEFORE
> >> any more patches, or changes are applied.  There has been enough
> >> changes, that even the simplest small change can make it a rebase
> >> nightmare.
> >>
> >> At this point, I will only accept patches on the rewrite
> >>
> > 
> > Fair enough. I'll just rebase the patch after the rewrite is merged.
> > 
> 
> We could just keep all of the repoman patches in a special branch.
> Then for each release, just do a 'git rebase master' in that branch,
> and then tag the resulting branch head as a release. After the
> rewrite is merged, I'll manually rebase them all on the rewrite.

I doubt you will be able to do a git rebase of old code patches onto
the new code.  It is just way too different.  most of the tests have
been removed from the main file and put into individual files. 

You'll likely have to hand apply them and adapt to the new code at the
same time.



-- 
Brian Dolbec 

Re: [gentoo-dev] [PATCH] eutils.eclass: Allow to configure base patch location for epatch_user

[Ulrich Mueller]

> On Sat, 5 Sep 2015, Rich Freeman wrote:

> I certainly support the principle, but for the sake of transparency
> can we try to coordinate this so that the setting name doesn't
> change when this moves into the package manager for EAPI6?

So far, the EAPI 6 draft says [1]:

   eapply_user
   Takes no arguments. Package managers supporting it apply
   user-provided patches to the source tree in the current working
   directory. Exact behaviour is implementation defined and beyond
   the scope of this specification. Package managers not supporting
   it must implement the function as a no-op. Only available in
   EAPIs listed in table [...] as supporting eapply_user.

> PMS is more about the content of the ebuilds, so presumably all
> package managers could structure how patches are provided by the
> user in whatefver way is most consistent with how they already
> operate.

Exactly, IMHO we should leave the details how this is implemented
to the package manager (including the option not to implement it).
This is of course open for discussion.

Ulrich

[1] 
https://gitweb.gentoo.org/proj/pms.git/diff/pkg-mgr-commands.tex?h=eapi-6=c82042d29a03defbb639050e5b3d265f74cbbee6


pgpvhuGFBKwym.pgp
Description: PGP signature

Re: [gentoo-dev] [PATCH] eutils.eclass: Allow to configure base patch location for epatch_user

[Rich Freeman]

On Sat, Sep 5, 2015 at 6:46 AM, Julian Ospald  wrote:
> This is particularly useful for people who run alternative
> package managers and want to control their configuration.

I certainly support the principle, but for the sake of transparency
can we try to coordinate this so that the setting name doesn't change
when this moves into the package manager for EAPI6?  PMS is more about
the content of the ebuilds, so presumably all package managers could
structure how patches are provided by the user in whatefver way is
most consistent with how they already operate.

--
Rich

Re: [gentoo-dev] [PATCH] eutils.eclass: Allow to configure base patch location for epatch_user

[hasufell]

On 09/05/2015 06:14 PM, Guilherme Amadio wrote:
> On Sat, Sep 05, 2015 at 02:42:15PM +0200, Ulrich Mueller wrote:
>>> On Sat, 5 Sep 2015, Rich Freeman wrote:
>>
>>> I certainly support the principle, but for the sake of transparency
>>> can we try to coordinate this so that the setting name doesn't
>>> change when this moves into the package manager for EAPI6?
>>
>> So far, the EAPI 6 draft says [1]:
>>
>>eapply_user
>>Takes no arguments. Package managers supporting it apply
>>user-provided patches to the source tree in the current working
>>directory. Exact behaviour is implementation defined and beyond
>>the scope of this specification. Package managers not supporting
>>it must implement the function as a no-op. Only available in
>>EAPIs listed in table [...] as supporting eapply_user.
> 
> Is there a reason to pick eapply_user rather than epatch_user? I think
> the second one would fit better with what we already have.
> Alternatively, if we would like to avoid adding a new function, it could
> be something like epatch --user or epatch -d $DIRECTORY_WITH_PATCHES,
> where $DIRECTORY_WITH_PATCHES either defaults to something like
> $EPATCH_SOURCE_USER, or can be specified via package.env. This takes the
> burden away from the package manager for where to put patches, and lets
> the user make that choice.
> 

Please start a new thread for discussing EAPI-6 features.  This is
offtopic here.

Re: [gentoo-dev] [PATCH] eutils.eclass: Allow to configure base patch location for epatch_user

[Rich Freeman]

On Sat, Sep 5, 2015 at 8:46 AM, hasufell  wrote:
> On 09/05/2015 02:42 PM, Ulrich Mueller wrote:
>>> On Sat, 5 Sep 2015, Rich Freeman wrote:
>>
>>> I certainly support the principle, but for the sake of transparency
>>> can we try to coordinate this so that the setting name doesn't
>>> change when this moves into the package manager for EAPI6?
>>
>> So far, the EAPI 6 draft says [1]:
>>
>>eapply_user
>>Takes no arguments. Package managers supporting it apply
>>user-provided patches to the source tree in the current working
>>directory. Exact behaviour is implementation defined and beyond
>>the scope of this specification. Package managers not supporting
>>it must implement the function as a no-op. Only available in
>>EAPIs listed in table [...] as supporting eapply_user.
>>
>>> PMS is more about the content of the ebuilds, so presumably all
>>> package managers could structure how patches are provided by the
>>> user in whatefver way is most consistent with how they already
>>> operate.
>>
>> Exactly, IMHO we should leave the details how this is implemented
>> to the package manager (including the option not to implement it).
>> This is of course open for discussion.
>>
>
> Right, I don't even see a reason to make the patch location configurable
> once it is implemented in package managers.
>
> This is really just about eutils.eclass.
>

I wasn't suggesting that the configuration of the path be made a part of PMS.

I was suggesting that somebody talk to the portage developers about
how they intend to implement EAPI6 so that users don't have to go into
their make.conf and change EPATCH_USER_SOURCE to EAPPY_USER_SOURCE or
something silly like that, or more likely define both since pre-6
ebuilds will use one setting and post-6 ebuilds will use the other.

I do realize that there is no technical constraint that forces us to
be nice to our users.  It's just good manners.  :)

(And I do realize that portage isn't the only package manager out
there.  By all means try to do this in a way that is easiest on users
of all of them.)

-- 
Rich

Re: [gentoo-dev] [PATCH] eutils.eclass: Allow to configure base patch location for epatch_user

[Guilherme Amadio]

On Sat, Sep 05, 2015 at 02:42:15PM +0200, Ulrich Mueller wrote:
> > On Sat, 5 Sep 2015, Rich Freeman wrote:
> 
> > I certainly support the principle, but for the sake of transparency
> > can we try to coordinate this so that the setting name doesn't
> > change when this moves into the package manager for EAPI6?
> 
> So far, the EAPI 6 draft says [1]:
> 
>eapply_user
>Takes no arguments. Package managers supporting it apply
>user-provided patches to the source tree in the current working
>directory. Exact behaviour is implementation defined and beyond
>the scope of this specification. Package managers not supporting
>it must implement the function as a no-op. Only available in
>EAPIs listed in table [...] as supporting eapply_user.

Is there a reason to pick eapply_user rather than epatch_user? I think
the second one would fit better with what we already have.
Alternatively, if we would like to avoid adding a new function, it could
be something like epatch --user or epatch -d $DIRECTORY_WITH_PATCHES,
where $DIRECTORY_WITH_PATCHES either defaults to something like
$EPATCH_SOURCE_USER, or can be specified via package.env. This takes the
burden away from the package manager for where to put patches, and lets
the user make that choice.

Cheers,
—Guilherme

Re: [gentoo-dev] [PATCH] eutils.eclass: Allow to configure base patch location for epatch_user

[hasufell]

On 09/05/2015 02:07 PM, Rich Freeman wrote:
> On Sat, Sep 5, 2015 at 6:46 AM, Julian Ospald  wrote:
>> This is particularly useful for people who run alternative
>> package managers and want to control their configuration.
> 
> I certainly support the principle, but for the sake of transparency
> can we try to coordinate this so that the setting name doesn't change
> when this moves into the package manager for EAPI6?  PMS is more about
> the content of the ebuilds, so presumably all package managers could
> structure how patches are provided by the user in whatefver way is
> most consistent with how they already operate.
> 

Of course, PMS should not refer to directories like "/etc/portage", but
I am not sure it's the place to introduce variables for users to
configure their PM behavior. I'd rather expect this to be PM-specific.
At that point, probably nothing will change for portage users anyway.
Everything else is not within our control.

Re: [gentoo-dev] [PATCH] eutils.eclass: Allow to configure base patch location for epatch_user

[hasufell]

On 09/05/2015 02:42 PM, Ulrich Mueller wrote:
>> On Sat, 5 Sep 2015, Rich Freeman wrote:
> 
>> I certainly support the principle, but for the sake of transparency
>> can we try to coordinate this so that the setting name doesn't
>> change when this moves into the package manager for EAPI6?
> 
> So far, the EAPI 6 draft says [1]:
> 
>eapply_user
>Takes no arguments. Package managers supporting it apply
>user-provided patches to the source tree in the current working
>directory. Exact behaviour is implementation defined and beyond
>the scope of this specification. Package managers not supporting
>it must implement the function as a no-op. Only available in
>EAPIs listed in table [...] as supporting eapply_user.
> 
>> PMS is more about the content of the ebuilds, so presumably all
>> package managers could structure how patches are provided by the
>> user in whatefver way is most consistent with how they already
>> operate.
> 
> Exactly, IMHO we should leave the details how this is implemented
> to the package manager (including the option not to implement it).
> This is of course open for discussion.
> 

Right, I don't even see a reason to make the patch location configurable
once it is implemented in package managers.

This is really just about eutils.eclass.

Re: [gentoo-portage-dev] [PATCH v2] repoman: ignore unadded files when possible (bug 559636)

[Zac Medico]

On 09/05/2015 09:18 AM, Zac Medico wrote:
> On 09/05/2015 09:16 AM, Brian Dolbec wrote:
>> On Sat,  5 Sep 2015 07:31:27 -0700
>> Zac Medico  wrote:
>>
>>> Unadded files that are excluded from the Manifest are safe to ignore.
>>>
>>> X-Gentoo-Bug: 559636
>>> X-Gentoo-Bug-url: https://bugs.gentoo.org/show_bug.cgi?id=559636
>>> ---
>>> [PATCH v2] fixes it to properly check the find_invalid_path_char
>>> return value bin/repoman | 6 +-
>>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/bin/repoman b/bin/repoman
>>> index 1ba7841..2c42c2d 100755
>>> --- a/bin/repoman
>>> +++ b/bin/repoman
>>> @@ -2570,7 +2570,11 @@ else:
>>> if myunadded:
>>> for x in range(len(myunadded)-1, -1, -1):
>>> xs = myunadded[x].split("/")
>>> -   if xs[-1] == "files":
>>> +   if
>>> repo_config.find_invalid_path_char(myunadded[x]) != -1:
>>> +   # The Manifest excludes this file,
>>> +   # so it's safe to ignore.
>>> +   del myunadded[x]
>>> +   elif xs[-1] == "files":
>>> print("!!! files dir is not added!
>>> Please correct this.") sys.exit(-1)
>>> elif xs[-1] == "Manifest":
>>
>> uhg :( not another patch to "old" repoman code.
>>
>> I really want to get the rewrite code into portage master BEFORE any
>> more patches, or changes are applied.  There has been enough changes,
>> that even the simplest small change can make it a rebase nightmare.
>>
>> At this point, I will only accept patches on the rewrite
>>
> 
> Fair enough. I'll just rebase the patch after the rewrite is merged.
> 

We could just keep all of the repoman patches in a special branch. Then
for each release, just do a 'git rebase master' in that branch, and then
tag the resulting branch head as a release. After the rewrite is merged,
I'll manually rebase them all on the rewrite.
-- 
Thanks,
Zac