[gentoo-dev] Request for feedback on GNU Patch change

[gentoo-dev] Request for feedback on GNU Patch change

["C. Bergström"]

To start.. I humbly ask for no response vs starting a flamewar..

Short version:
The proposed change will require changes in two places, but may cause 
other breakage and or simply not settle well with general consensus.

1) Add a symlink in GNU patch ebuild to symlink patch to gpatch

2) Change references to patch in eclass/eutils.eclass to gpatch
---------

Benefit is that on systems != Linux where GNU patch exists in the 
subpath to some crappy legacy thing which probably shouldn't even be 
called patch.. On these systems calling gpatch explicitly means GNU 
patch and avoids the whole PATH and incompatibility issue.

Would this benefit those working on the FBSD?
Anyone interested in OpenSolaris?

I have other changes I'm making to remove GNUisms, but this one I'm not 
seeing much hope for and will pop up on every emerge --sync..

patch -p0 -g0 -E --no-backup-if-mismatch < /opt/foo/bar.patch

Suggestions?

Thanks

./Christopher

[gentoo-dev] Re: Request for feedback on GNU Patch change

[Duncan]

"C. Bergström" <cbergstrom@netsyncro.com> posted
48D0177B.2010002@netsyncro.com, excerpted below, on  Tue, 16 Sep 2008
22:30:51 +0200:

> 1) Add a symlink in GNU patch ebuild to symlink patch to gpatch

You mean the other way, right?  gpatch -> patch , since we already have 
patch, and need gpatch if the below is to work.

Or did you mean change the sys-devel/patch ebuild so the executable is 
named gpatch instead of patch, then create a symlink patch -> gpatch as 
suggested above.

> 2) Change references to patch in eclass/eutils.eclass to gpatch

This makes sense to me.

-- 
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

Re: [gentoo-dev] Re: Request for feedback on GNU Patch change

["C. Bergström"]

Duncan wrote:
> "C. Bergström" <cbergstrom@netsyncro.com> posted
> 48D0177B.2010002@netsyncro.com, excerpted below, on  Tue, 16 Sep 2008
> 22:30:51 +0200:
>
>   
>> 1) Add a symlink in GNU patch ebuild to symlink patch to gpatch
>>     
>
> You mean the other way, right?  gpatch -> patch , since we already have 
> patch, and need gpatch if the below is to work.
>
> Or did you mean change the sys-devel/patch ebuild so the executable is 
> named gpatch instead of patch, then create a symlink patch -> gpatch as 
> suggested above.
>
>   
>> 2) Change references to patch in eclass/eutils.eclass to gpatch
>>     
>
> This makes sense to me.
>
>   
Here's another idea and I don't know why I didn't think of it sooner..  
Instead of any system change to the patch ebuild.. Inside the 
eutils.eclass do a quick check for gpatch and if it exists use that vs 
patch.  I'm trying to think of any circumstances where this would fail..

Re: [gentoo-dev] Re: Request for feedback on GNU Patch change

[Ulrich Mueller]

>>>>> On Wed, 17 Sep 2008, C. Bergström wrote:

> Here's another idea and I don't know why I didn't think of it
> sooner.. Instead of any system change to the patch ebuild.. Inside
> the eutils.eclass do a quick check for gpatch and if it exists use
> that vs patch.

Why not simply alias patch=gpatch in profile.bashrc?
See the FreeBSD profile for an example.

Ulrich

Re: [gentoo-dev] Re: Request for feedback on GNU Patch change

["C. Bergström"]

Ulrich Mueller wrote:
>>>>>> On Wed, 17 Sep 2008, C. Bergström wrote:
>>>>>>             
>
>   
>> Here's another idea and I don't know why I didn't think of it
>> sooner.. Instead of any system change to the patch ebuild.. Inside
>> the eutils.eclass do a quick check for gpatch and if it exists use
>> that vs patch.
>>     
>
> Why not simply alias patch=gpatch in profile.bashrc?
> See the FreeBSD profile for an example.
>   
I'd like to package portage for OpenSolaris and have it just drop-in 
work so modifications like what you suggest wouldn't be required.  
Hopefully, base-system maintainers don't mind my request, but I can 
understand it's beyond the Linux use case.

Re: [gentoo-dev] Re: Request for feedback on GNU Patch change

[Fabian Groffen]

On 17-09-2008 09:59:42 +0200, "C. Bergström" wrote:
>> Why not simply alias patch=gpatch in profile.bashrc?
>> See the FreeBSD profile for an example.
>>   
> I'd like to package portage for OpenSolaris and have it just drop-in  
> work so modifications like what you suggest wouldn't be required.   
> Hopefully, base-system maintainers don't mind my request, but I can  
> understand it's beyond the Linux use case.

As I understood it, you want to package (Prefix) Portage for
(Open)Solaris, but without USERLAND=GNU like Gentoo Prefix does.  You
want all eclasses, ebuilds and portage itself to work with the Solaris
userland tools.


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] Re: Request for feedback on GNU Patch change

["C. Bergström"]

Fabian Groffen wrote:
> On 17-09-2008 09:59:42 +0200, "C. Bergström" wrote:
>   
>>> Why not simply alias patch=gpatch in profile.bashrc?
>>> See the FreeBSD profile for an example.
>>>   
>>>       
>> I'd like to package portage for OpenSolaris and have it just drop-in  
>> work so modifications like what you suggest wouldn't be required.   
>> Hopefully, base-system maintainers don't mind my request, but I can  
>> understand it's beyond the Linux use case.
>>     
>
> As I understood it, you want to package (Prefix) Portage for
> (Open)Solaris, but without USERLAND=GNU like Gentoo Prefix does.  You
> want all eclasses, ebuilds and portage itself to work with the Solaris
> userland tools.
>
>   
Not exactly..

1) yes I'm patching (prefix) portage for OpenSolaris.. I say OpenSolaris 
because while I'm doing best effort to make it as portable as possible, 
but can't test and don't much care about prior versions w/o source.

2) OpenSolaris comes with most GNU tools by default (except sed/find) , 
but appends a g to the front
File: `/usr/gnu/bin/sed' -> `../../bin/gsed'

I'd happily not bring this issue and bother anyone, but on every sync 
that eclass is going to get overwritten and the change is pretty minimal.

In regards to the ebuilds I will manage an overlay containing mostly 
repackaged sources from upstream.  The end goal being able to repackage 
the entire OpenSolaris distribution built with portage from source.

Thanks for the minute

./Chrisotpher

Re: [gentoo-dev] Re: Request for feedback on GNU Patch change

[Santiago M. Mola]

On Wed, Sep 17, 2008 at 9:59 AM, "C. Bergström"
<cbergstrom@netsyncro.com> wrote:
> Ulrich Mueller wrote:
>>>>>>> On Wed, 17 Sep 2008, C. Bergström wrote:
>>>>>>>
>>
>>
>>>
>>> Here's another idea and I don't know why I didn't think of it
>>> sooner.. Instead of any system change to the patch ebuild.. Inside
>>> the eutils.eclass do a quick check for gpatch and if it exists use
>>> that vs patch.
>>>
>>
>> Why not simply alias patch=gpatch in profile.bashrc?
>> See the FreeBSD profile for an example.
>>
>
> I'd like to package portage for OpenSolaris and have it just drop-in work so
> modifications like what you suggest wouldn't be required.

You'd still need to create an OpenSolaris profile. While you're at it,
you can create a profile.bashrc with the required modifications.

I don't see any reason to not do the gpatch change, but it looks like
unecessary to me because you already have simpler ways to solve the
problem. So, requiring others to do a significant useless amount of
work when you can solve it with just a line is not fair.

Regards,
-- 
Santiago M. Mola
Jabber ID: cooldwind@gmail.com

Re: [gentoo-dev] Re: Request for feedback on GNU Patch change

[Fabian Groffen]

On 17-09-2008 10:21:17 +0200, Santiago M. Mola wrote:
> >> Why not simply alias patch=gpatch in profile.bashrc?
> >> See the FreeBSD profile for an example.
> >>
> >
> > I'd like to package portage for OpenSolaris and have it just drop-in work so
> > modifications like what you suggest wouldn't be required.
> 
> You'd still need to create an OpenSolaris profile. While you're at it,
> you can create a profile.bashrc with the required modifications.
> 
> I don't see any reason to not do the gpatch change, but it looks like
> unecessary to me because you already have simpler ways to solve the
> problem. So, requiring others to do a significant useless amount of
> work when you can solve it with just a line is not fair.

From some experience, I can tell that an alias is not sufficient to
cover all cases, and will result in random failures because you only
notice too late patch is used and not gpatch.

By the way, I'm against this stuff.  I rather see a PATH solution
involved.  Portage already has a DEFAULT_PATH, and if someone refuses to
install patch, one could always use a special directory with symlinks to
the g-versions, e.g. patch -> /usr/sfw/bin/gpatch such that
Portage/eclass/ebuilds don't have to bother about this at all.


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] Re: Request for feedback on GNU Patch change

["C. Bergström"]

Fabian Groffen wrote:
> On 17-09-2008 10:21:17 +0200, Santiago M. Mola wrote:
>   
>>>> Why not simply alias patch=gpatch in profile.bashrc?
>>>> See the FreeBSD profile for an example.
>>>>
>>>>         
>>> I'd like to package portage for OpenSolaris and have it just drop-in work so
>>> modifications like what you suggest wouldn't be required.
>>>       
>> You'd still need to create an OpenSolaris profile. While you're at it,
>> you can create a profile.bashrc with the required modifications.
>>
>> I don't see any reason to not do the gpatch change, but it looks like
>> unecessary to me because you already have simpler ways to solve the
>> problem. So, requiring others to do a significant useless amount of
>> work when you can solve it with just a line is not fair.
>>     
>
> >From some experience, I can tell that an alias is not sufficient to
> cover all cases, and will result in random failures because you only
> notice too late patch is used and not gpatch.
>
> By the way, I'm against this stuff.  I rather see a PATH solution
> involved.  Portage already has a DEFAULT_PATH, and if someone refuses to
> install patch, one could always use a special directory with symlinks to
> the g-versions, e.g. patch -> /usr/sfw/bin/gpatch such that
> Portage/eclass/ebuilds don't have to bother about this at all.
>   
patch is installed and I would agree with you, but in certain 
circumstances using the GNU tools are broken.

Re: [gentoo-dev] Re: Request for feedback on GNU Patch change

[Fabian Groffen]

On 17-09-2008 10:41:07 +0200, "C. Bergström" wrote:
>> By the way, I'm against this stuff.  I rather see a PATH solution
>> involved.  Portage already has a DEFAULT_PATH, and if someone refuses to
>> install patch, one could always use a special directory with symlinks to
>> the g-versions, e.g. patch -> /usr/sfw/bin/gpatch such that
>> Portage/eclass/ebuilds don't have to bother about this at all.
>>   
> patch is installed and I would agree with you, but in certain  
> circumstances using the GNU tools are broken.

Then if that is the case, Portage/eclass/ebuild relies on that
brokenness.  I'm not saying you should have the same PATH as Portage.


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] Re: Request for feedback on GNU Patch change

["C. Bergström"]

Fabian Groffen wrote:
> On 17-09-2008 10:41:07 +0200, "C. Bergström" wrote:
>   
>>> By the way, I'm against this stuff.  I rather see a PATH solution
>>> involved.  Portage already has a DEFAULT_PATH, and if someone refuses to
>>> install patch, one could always use a special directory with symlinks to
>>> the g-versions, e.g. patch -> /usr/sfw/bin/gpatch such that
>>> Portage/eclass/ebuilds don't have to bother about this at all.
>>>   
>>>       
>> patch is installed and I would agree with you, but in certain  
>> circumstances using the GNU tools are broken.
>>     
>
> Then if that is the case, Portage/eclass/ebuild relies on that
> brokenness.  I'm not saying you should have the same PATH as Portage.
>   
GNU tools always behaved as expected on Linux.  The brokeness is 
platform specific in my case.  Anyway, I'm pretty sure you use Solaris 
in production and I'm just trying to make the situation easier.  If 
someone will review the patch I'll make it up, but don't want to waste 
more of anyone's time on this.

Thanks

Re: [gentoo-dev] Re: Request for feedback on GNU Patch change

[Thilo Bangert]

[-- Attachment #1: Type: text/plain, Size: 979 bytes --]

"C. Bergström" <cbergstrom@netsyncro.com> said:
> Fabian Groffen wrote:
> > On 17-09-2008 10:41:07 +0200, "C. Bergström" wrote:
> >>> By the way, I'm against this stuff.  I rather see a PATH solution
> >>> involved.  Portage already has a DEFAULT_PATH, and if someone
> >>> refuses to install patch, one could always use a special directory
> >>> with symlinks to the g-versions, e.g. patch -> /usr/sfw/bin/gpatch
> >>> such that Portage/eclass/ebuilds don't have to bother about this at
> >>> all.
> >>
> >> patch is installed and I would agree with you, but in certain
> >> circumstances using the GNU tools are broken.
> >
> > Then if that is the case, Portage/eclass/ebuild relies on that
> > brokenness.  I'm not saying you should have the same PATH as Portage.
>
> GNU tools always behaved as expected on Linux.  The brokeness is
> platform specific in my case.  

please, also make sure this gets fixed. 
thanks for your work

kind regards
Thilo

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-dev] Re: Re: Request for feedback on GNU Patch change

[Steve Long]

Fabian Groffen wrote:

> On 17-09-2008 10:21:17 +0200, Santiago M. Mola wrote:
>> >> Why not simply alias patch=gpatch in profile.bashrc?
>> >> See the FreeBSD profile for an example.
>> >>
>> >
>> > I'd like to package portage for OpenSolaris and have it just drop-in
>> > work so modifications like what you suggest wouldn't be required.
>> 
>> You'd still need to create an OpenSolaris profile. While you're at it,
>> you can create a profile.bashrc with the required modifications.
>> 
>> I don't see any reason to not do the gpatch change, but it looks like
>> unecessary to me because you already have simpler ways to solve the
>> problem. So, requiring others to do a significant useless amount of
>> work when you can solve it with just a line is not fair.
> 
> From some experience, I can tell that an alias is not sufficient to
> cover all cases, and will result in random failures because you only
> notice too late patch is used and not gpatch.
>
alias only works for stuff that bash parses as a command on tokenisation. So
it won't work for anything called via a variable, or find -exec/xargs.
(Note also the standard way to get round an alias: \foo or `command foo'.)
 
> By the way, I'm against this stuff.  I rather see a PATH solution
> involved.  Portage already has a DEFAULT_PATH, and if someone refuses to
> install patch, one could always use a special directory with symlinks to
> the g-versions, e.g. patch -> /usr/sfw/bin/gpatch such that
> Portage/eclass/ebuilds don't have to bother about this at all.
> 
I agree. PATH+=':/blah/bar', or PATH="/blah/bar:$PATH" if you want it
considered first.

The alternative would be a variable for every utility that could conceivably
be called, and then every ebuild would need to use those, which is a
maintenance nightmare imo. I guess you could ban use of -exec/xargs but I
don't think that's likely ever to happen.

Re: [gentoo-dev] Re: Request for feedback on GNU Patch change

["C. Bergström"]

Santiago M. Mola wrote:
> On Wed, Sep 17, 2008 at 9:59 AM, "C. Bergström"
> <cbergstrom@netsyncro.com> wrote:
>   
>> Ulrich Mueller wrote:
>>     
>>>>>>>> On Wed, 17 Sep 2008, C. Bergström wrote:
>>>>>>>>
>>>>>>>>                 
>>>       
>>>> Here's another idea and I don't know why I didn't think of it
>>>> sooner.. Instead of any system change to the patch ebuild.. Inside
>>>> the eutils.eclass do a quick check for gpatch and if it exists use
>>>> that vs patch.
>>>>
>>>>         
>>> Why not simply alias patch=gpatch in profile.bashrc?
>>> See the FreeBSD profile for an example.
>>>
>>>       
>> I'd like to package portage for OpenSolaris and have it just drop-in work so
>> modifications like what you suggest wouldn't be required.
>>     
>
> You'd still need to create an OpenSolaris profile. While you're at it,
> you can create a profile.bashrc with the required modifications.
>
> I don't see any reason to not do the gpatch change, but it looks like
> unecessary to me because you already have simpler ways to solve the
> problem. So, requiring others to do a significant useless amount of
> work when you can solve it with just a line is not fair.
>   
If I don't have to introduce a new bash dependency I'd like to avoid it.

I'll do the work. The patch is a couple lines and I don't think it would 
be significant or impact maintenance of the eclass.