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

[Alexander Leidinger]

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.

-- 
Failure is not an option. It comes bundled with your Microsoft product.
http://www.Leidinger.net                       Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7
WL http://www.amazon.de/exec/obidos/registry/1FZ4DTHQE9PQ8/ref=wl_em_to/