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

[Alexander Leidinger]

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

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.

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

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.

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.

-- 
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org     netchild @ FreeBSD.org  : PGP ID = 72077137
Better hope the life-inspector doesn't come
around while you have your life in such a mess.