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>
index | next in thread | previous in thread | raw e-mail
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
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43EC86B4.6060600>