Date: Fri, 10 Feb 2006 07:27:32 -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: <43EC86B4.6060600@vonostingroup.com> In-Reply-To: <20060210101931.k017bqbpus8gosws@netchild.homeip.net> References: <200602081940.k18Je7uC012039@freefall.freebsd.org> <20060209202602.1449abba.jylefort@FreeBSD.org> <20060210101931.k017bqbpus8gosws@netchild.homeip.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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,
and modifying a read-only variable is only asking for trouble down the line.
> 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
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.
>
>
> 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 will also contact portmgr to coordinate the testing.
>
> 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.
>
> 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.
Regards,
Frank
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43EC86B4.6060600>