ports/91911: [PATCH]: x11-toolkits/linux-gtk2: distfile unfetchable

[Frank J. Laszlo]

Alexander Leidinger wrote:
> Am Fri, 10 Feb 2006 07:27:32 -0500
> schrieb "Frank J. Laszlo" <laszlof at vonostingroup.com>:
>
>   
>> Alexander Leidinger wrote:
>>     
>>> Jean-Yves Lefort <jylefort at FreeBSD.org> wrote:
>>>
>>>       
>>>>>  Let me guess: you are trying to install acroread7 while linux-gtk2
>>>>>  isn't installed.
>>>>>
>>>>>  You get this error message because of a bug in bsd.port.mk (or in the
>>>>>  acroread7 port, depending on your point of view...).
>>>>>
>>>>>  The linux-gtk2 port is just fine. Install it by hand instead of a
>>>>>  dependency of the acroread port and it should work just fine.
>>>>>           
>>>> Alexander, as you've been told many times now the acroread7 port is
>>>> fine (with regard to that issue at least); the bug is in bpm or in the
>>>> linux ports which override ARCH. I suggest to commit Frank Laszlo's
>>>> patches, since modifying bpm is a tedious process.
>>>>         
>>> I don't doupt that bpm has a problem in this case. And I agree that we 
>>> may be
>>> able to come up with a better solution for the linux ports. But I 
>>> don't agree
>>> that the acroread port is fine. It doesn't fit into the way most of 
>>> the linux
>>> ports work ATM, so it doesn't play well with the rest, so it's broken 
>>> in this
>>> regard. So the short-time fix for the acroread port would be to add 
>>> the same
>>> ARCH shuffling as the other ports have (see below).
>>>
>>>       
>> Just because all the other linux ports do this, doesn't make it right, 
>>     
>
> I didn't said this. I agree that the current way of doing it should be
> revised. But as already said, the work-around is enough for the release.
>
>   
>> and modifying a read-only variable is only asking for trouble down the line.
>>     
>
> Since we only talk about the linux ports: only in the known cases like
> acroread.
>
>   
>>> Yes, the use of a different variable name in the linux ports is a 
>>> better fix
>>> for this. No, I don't want to commit Frank's patches. Not because they 
>>> are
>>> blatantly wrong, but because I don't agree with the name of the variable
>>> used. SUB_ARCH is very generic, while your use of LINUX_RPM_ARCH in
>>> bsd.linux-rpm.mk looks much better.
>>>       
>> Whats wrong with SUB_ARCH? (Substitute ARCH) And if the functionality 
>>     
>
> It is very generic and is not as obvious as the one Jean-Yves uses in
> bsd.linux-rpm.mk.
>
>   
>> for this is allready in bsd.linux-rpm.mk, why dont we use it? (I just 
>> noticed the code there myself) Theres no point is re-writing code thats 
>> allready implemented.
>>     
>
> bsd.linux-rpm.mk is new and so far nobody converted the other ports to
> use it. Converting all of the linux ports which use the code in the
> linux-gtk Makefile is on my TODO list, but I hadn't time yet. And such
> a large change should be tested on the ports build cluster first. Feel
> free to submit patches (but don't expect me to integrate them before
> the release).
>
> Additionally: AFAIK the amd64 people didn't mass-converted all linux
> ports, because each port has to be tested. Some ports already needed
> some fixes in the amd64 case. So blindly using bsd.linux-rpm.mk even
> for ports which don't have the ARCH-shuffling code is not a good
> solution.
>
>   
>>> If someone comes up with a patch which changes all linux ports which 
>>> do the
>>> ARCH-shuffling thing to use LINUX_RPM_ARCH instead, I try to get time and
>>> commit this (after coordinating with portmgr because of the
>>> "no-sweeping-changes flag"). I also don't mind if someone else commits 
>>> such
>>> patches (after coordinating with portmgr).
>>>       
>> I'd be more than happy to modify my patches to do this. I have included 
>> ALL the ports that toy with ARCH, at least the linux specific ones. And
>>     
>
> I was only talking about the linux specific ones. Regarding the
> renaming of SUB_ARCH to LINUX_RPM_ARCH: it can be done just be piping
> the patches through "s:SUB_ARCH:LINUX_RPM_ARCH:g". It's something a
> committer can do before he asks portmgr for testing this.
>
> _I_ will not ask portmgr to test this before the release. Partly
> because of personal time constraints, partly because I think the
> work-around in the acroread7 port is enough until the release.
>
> After the release I'm more than willing to test the ARCH changes or
> bsd.linux-rpm.mk patches for the linux ports.
>
>   
>> I will also contact portmgr to coordinate the testing.
>>     
>
> That work should be done by the committer who is willing to commit the
> changes.
>
>   
>>> But I don't think we need to rush this out before the ports freeze. It 
>>> would
>>> be enough to commit the ARCH-shuffling part to the acroread port and 
>>> let the
>>> RELEASEs ship with it. After the ports freeze it could then be fixed 
>>> properly
>>> without time pressure.
>>>       
>> acroread7 will not build for most people on amd64. I think this is a 
>> pretty darn good reason to rush the fixes out.
>>     
>
> No. There's a work-around available. It may be not the greatest
> solution, but it's a usable solution which works until the time is
> right to do the better fix.
>
>   
>>> It's not only about doing it right, it's also about time constraints and
>>> about not breaking things for our userbase (or new users of the upcoming
>>> release). And it's not only about time constraints of those committers,
>>> which are willing to handle it (and have time to fix bugs in case some 
>>> slip
>>> into the commit), but also about project related time constraints 
>>> (release
>>> related freezes, maybe portmgr want's to do a experimental run of those
>>> patches on the cluster, ...). The update to the current linux_base 
>>> version
>>> was done shortly before a release, and kris and I spend the days around
>>> christmas to get it into a good shape. The update was necessary 
>>> because of
>>> security issues, and I think my time was spend well at that time, 
>>> since we
>>> where able to ship with a usable linuxolator (I don't remember any major
>>> bugs, and I changed a lot of ports). The change both of you propose 
>>> has an
>>> impact on a lot of ports (because of the use of the linux-gtk Makefile 
>>> in a
>>> lot of other ports), and I don't think we absolutely need to do such a
>>> sweeping change before the release since there not such a heavy wight 
>>> reason
>>> like we had with the linux_base update. There's an easy and small 
>>> work-around
>>> for the acroread port available and it doesn't hurt to commit it, so 
>>> there's
>>> no need to force the inclusion of the "architecturally(sp?) right fix".
>>>
>>> Bye,
>>> Alexander.
>>>
>>>       
>> This is why we need to have people test the patches before we do 
>> anything. I'll get on this later today and get back with you all.
>>     
>
> And you really think _enough_ people will do _the right tests_ *before
> the release*?
>
> Bye,
> Alexander.
>
>   


I can see this isnt going to be fixed before the ports freeze.. so I'll 
leave it to the commiters to handle it from here on out. Since they did 
such a good job making these linux ports work on amd64 in the first place.

Regards,
    Frank