Date: Sat, 11 Feb 2006 09:06:45 -0500 From: "Frank J. Laszlo" <laszlof@vonostingroup.com> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: Jean-Yves Lefort <jylefort@FreeBSD.org>, freebsd-emulation@FreeBSD.org Subject: Re: ports/91911: [PATCH]: x11-toolkits/linux-gtk2: distfile unfetchable Message-ID: <43EDEF75.10707@vonostingroup.com> In-Reply-To: <20060211135019.335f3ed2@Magellan.Leidinger.net> References: <200602081940.k18Je7uC012039@freefall.freebsd.org> <20060209202602.1449abba.jylefort@FreeBSD.org> <20060210101931.k017bqbpus8gosws@netchild.homeip.net> <43EC86B4.6060600@vonostingroup.com> <20060211135019.335f3ed2@Magellan.Leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Alexander Leidinger wrote:
> Am Fri, 10 Feb 2006 07:27:32 -0500
> schrieb "Frank J. Laszlo" <laszlof@vonostingroup.com>:
>
>
>> Alexander Leidinger wrote:
>>
>>> Jean-Yves Lefort <jylefort@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43EDEF75.10707>