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