From owner-freebsd-emulation@FreeBSD.ORG Fri Dec 2 15:37:52 2005 Return-Path: X-Original-To: emulation@FreeBSD.org Delivered-To: freebsd-emulation@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A22716A41F for ; Fri, 2 Dec 2005 15:37:52 +0000 (GMT) (envelope-from jylefort@FreeBSD.org) Received: from host-212-68-242-42.brutele.be (host-212-68-242-42.brutele.be [212.68.242.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A4C443D5A for ; Fri, 2 Dec 2005 15:37:36 +0000 (GMT) (envelope-from jylefort@FreeBSD.org) Received: from jsite.lefort.net (jsite.lefort.net [192.168.1.2]) by gateway.lefort.net (Postfix) with ESMTP id 3ECCF54F0; Fri, 2 Dec 2005 16:37:35 +0100 (CET) Received: from jsite.lefort.net (localhost [127.0.0.1]) by jsite.lefort.net (Postfix) with SMTP id D9B36C0DB; Fri, 2 Dec 2005 16:37:34 +0100 (CET) Date: Fri, 2 Dec 2005 16:37:34 +0100 From: Jean-Yves Lefort To: Alexander Leidinger Message-Id: <20051202163734.23814a2f.jylefort@FreeBSD.org> In-Reply-To: <20051202142827.2s3y42ss8w0o0g0o@netchild.homeip.net> References: <200511261918.jAQJIp91001719@repoman.freebsd.org> <20051201152026.lxwvpjokc0sw0okc@netchild.homeip.net> <20051202121534.44c2c7be.jylefort@FreeBSD.org> <20051202142827.2s3y42ss8w0o0g0o@netchild.homeip.net> X-Mailer: Sylpheed running on FreeBSD Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Fri__2_Dec_2005_16_37_34_+0100_Fu2vS5M.Xgt7sLJi" Cc: emulation@FreeBSD.org Subject: Re: cvs commit: ports/audio/linux-openal bsd.linux.mk X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2005 15:37:52 -0000 --Signature=_Fri__2_Dec_2005_16_37_34_+0100_Fu2vS5M.Xgt7sLJi Content-Type: multipart/mixed; boundary="Multipart=_Fri__2_Dec_2005_16_37_34_+0100_fhSp1jdguMFSR4dJ" --Multipart=_Fri__2_Dec_2005_16_37_34_+0100_fhSp1jdguMFSR4dJ Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, 02 Dec 2005 14:28:27 +0100 Alexander Leidinger wrote: > Jean-Yves Lefort wrote: >=20 > >> - install-time generated plists are evil (as per discussion on > >> ports@ a while ago (and as of very recent experience with the > >> linux ports), so the pre-install target should be removed and > >> a real plist should be generated), have a look at the linux-gtk > >> Makefile for a target which generates an initial plist (needs > >> to be modified a little bit afterwards) > > > > So we still don't agree on this. I guess we never will. :( >=20 > I don't object to autogenerated lists, I object to not commit the plist to > the ports tree. Add a target, e.g. "new-plist", which generates a new pli= st > in the directory of the port, and I don't object (have a look at > x11-toolkits/linux-gtk/Makefile). >=20 > We have several linux ports which contain empty directories. If port A and > the dependency port B both contain the same empty directory in the RPM, b= oth > plists will contain a "@dirrm" for this. This is wrong and pointyhat will > complain. You also need a "@exec mkdir" for such an empty directory, else > the package will not generate it. While it doesn't matter for pointyhat if > the second mkdir is there or not, ideally the directory should only be > crated once. From my pragmatic point of view: I don't care for the > superflous mkdir, but I care about the rmdir. I don't want to get bombard= ed > with YAPHR mails again for those errors. >=20 > Another class of errors are the locale directories. Not every locale dire= ctoy > is created by linux_base. linux-glib2 has to create some of them. linux-g= tk2 > uses some of those newly created ones. Those directories should not be > removed by linux-gtk2. Some other ports may use those directories too, but > some of them may not depend upon linx-glib2. The current workaround ist to > remove the locale directories if they are empty in every port. It works (= the > pragmatic solution) without YAPHR mails, but it's not clean. The linux-gt= k2 > port should not contain the "rmdir || true" parts for them. I am aware of these peculiarities. Ports for which the auto plist generator is not smart enough (they are a minority) can perfectly bypass it. As an example, see my own linux ports: audio/linux-alsa-lib, audio/linux-arts, audio/linux-libogg, audio/linux-libvorbis, audio/linux-openal and lang/linux-libgcc use the auto plist. x11-themes/linux-gtk-bluecurve-theme is affected by some of the issues you mention, and therefore builds its own plist in pre-install. > >> - it should be installed into PORTSDIR/Mk, so that other port can > >> use it > > > > I agree, but I don't think that I have the right to (nor that it is > > good to) add files to Mk/ without portmgr reviewal. > > > > I had planned to contact emulation@ and discuss the steps needed to > > move the file to Mk/ and have it pulled in from bsd.port.mk (via a > > USE_LINUX_RPM knob, or something). Glad to see that you read > > cvs-ports. :) >=20 > I suggest: > - ask portmgr if it is ok to commit the .mk file (not included by > bsd.port.mk) > - commit it if approved > - convert some ports to use it > - be happe when everything works > - write a patch for bsd.port.mk (USE_LINUX_RPM) and let portmgr > run an experimental ports build > - when portmgr committed the patch convert some ports to use it > - be happy when everything works > - convert the rest > - sit back and enjoy^w^w^w^wtackle another problem Good idea. I'm going to ask portmgr if I can commit the attached file, unless you have more comments. Major changes: - allow to easily disable auto plist by defining NO_AUTOMATIC_PLIST - added new-plist target inspired by linux-gtk - useful default for MASTER_SITE_SUBDIR (Fedora Core 3) - use run-ldconfig target and mimic native output Note that INSTALLS_SHLIB requires a bsd.port.mk patch, so I still have to use INSTALLS_LINUX_SHLIB. > >> - does the ppc have a linuxolator? > > > > I'm not sure (I guess not). I'll remove the powerpc stuff if someone > > confirms that there's no linux emulation on powerpc. >=20 > AFAIK ony amd64, alpha and i386 have a linuxolator. >=20 > I suggest to let the .mk part intact, maybe it motivates someone to write > some code for those other architectures. Just remove the already committed > .ppc files in the ports tree. That's what I did. > >> - why do you use different ways of specifying the paths in DESCR > >> and MD5_FILE? > >> - why do you specify DESCR at all? > > > > The idea is to use the FreeBSD native port's pkg-descr. >=20 > I don't think this is good. I think the descr should mention that the por= ts > provide the linux versions of the port. It's obvious from the package name and comment. But once again, people are free to bypass this helper if they don't like it. > > I don't know what to do next. I can file a PR for inclusion in Mk/, >=20 > An suggestion is already above. >=20 > > but it'd feature my own plist generator. Directions are welcome. >=20 > I hope we can meet in the middle and agree on the semi-automatic plist > generator. A new-plist target allows you to be lazy (since a maintainer is > supposed to test the port anyway, I don't think it's to much work to type > "make new-plist"... or "make new-plist && mv pkg-plist.new pkg-plist", see > linux-gtk/Makefile), while it allows those people which don't trust the > automatic plist generator to write their own plists. It also allows to lo= ok > up the contents of the port without a need to install it. And we're able = to > answer questions like "which port installs file X". So we get the good > features of both worlds, don't you think? I've added new-plist and NO_AUTOMATIC_PLIST for auto plist haters. --=20 Jean-Yves Lefort jylefort@FreeBSD.org http://lefort.be.eu.org/ --Multipart=_Fri__2_Dec_2005_16_37_34_+0100_fhSp1jdguMFSR4dJ Content-Type: text/plain; name="bsd.linux-rpm.mk" Content-Disposition: attachment; filename="bsd.linux-rpm.mk" Content-Transfer-Encoding: base64 IyBic2QubGludXgtcnBtLm1rIC0gc3VwcG9ydCBmb3IgUlBNIHBhY2thZ2VzIHdoaWNoIGluc3Rh bGwgaW4gJHtMSU5VWEJBU0V9DQojDQojIE1haW50YWluZXI6IEplYW4tWXZlcyBMZWZvcnQgPGp5 bGVmb3J0QEZyZWVCU0Qub3JnPg0KIw0KIyAkRnJlZUJTRCQNCiMNCg0KTUFTVEVSX1NJVEVTPz0J JHtNQVNURVJfU0lURV9GRURPUkFfTElOVVh9DQpNQVNURVJfU0lURV9TVUJESVI/PQkzLyR7TElO VVhfQVJDSH0vb3MvRmVkb3JhL1JQTVMvDQpQS0dOQU1FUFJFRklYPz0JbGludXgtDQpFWFRSQUNU X1NVRlg/PQkuJHtMSU5VWF9BUkNIfS5ycG0NCg0KRVhUUkFDVF9ERVBFTkRTKz0JcnBtMmNwaW86 JHtQT1JUU0RJUn0vYXJjaGl2ZXJzL3JwbQ0KDQpFWFRSQUNUX0NNRD89CXJwbTJjcGlvDQpFWFRS QUNUX0JFRk9SRV9BUkdTPz0NCkVYVFJBQ1RfQUZURVJfQVJHUz89CXwgJHtDUElPfSAtaWQgLS1x dWlldA0KDQpVU0VfTElOVVg9CXllcw0KVVNFX0xJTlVYX1BSRUZJWD0JeWVzDQoNCk5PX1dSS1NV QkRJUj0JeWVzDQpOT19CVUlMRD0JeWVzDQoNCkRFU0NSPz0JCSR7LkNVUkRJUn0vLi4vJHtQT1JU TkFNRX0vcGtnLWRlc2NyDQpNRDVfRklMRT89CSR7TUFTVEVSRElSfS9kaXN0aW5mby4ke0xJTlVY X0FSQ0h9DQoNCkxJTlVYX0xEQ09ORklHPz0JJHtMSU5VWEJBU0V9L3NiaW4vbGRjb25maWcNCg0K LmlmICFkZWZpbmVkKE5PX0FVVE9NQVRJQ19QTElTVCkNClBMSVNUPz0JCSR7V1JLRElSfS8uUExJ U1QubGludXgtcnBtDQoNCnByZS1pbnN0YWxsOiBsaW51eC1ycG0tZ2VuZXJhdGUtcGxpc3QNCg0K bGludXgtcnBtLWdlbmVyYXRlLXBsaXN0Og0KCUAke1JNfSAtZiAke1BMSVNUfQ0KCUBjZCAke1dS S1NSQ30gJiYgXA0KCSR7RklORH0gKiAhIC10eXBlIGQgfCAke1NPUlR9ID4+ICR7UExJU1R9ICYm IFwNCgkke0ZJTkR9IC1kICogLXR5cGUgZCBcDQoJCXwgJHtHUkVQfSAtRXYgJ14oZXRjfGxpYnx1 c3J8dXNyL2Jpbnx1c3IvbGlifHVzci9zYmlufHVzci9zaGFyZXx1c3Ivc2hhcmUvZG9jfHVzci9z aGFyZS9pbmZvfHVzci9zaGFyZS9tYW58dXNyL3NoYXJlL21hbi9tYW5bMS05bl0pJCQnIFwNCgkJ fCAke1NFRH0gLWUgJ3N8XnxAZGlycm0gfCcgPj4gJHtQTElTVH0NCi5lbmRpZg0KDQouaWYgIXRh cmdldChkby1pbnN0YWxsKQ0KZG8taW5zdGFsbDoNCgljZCAke1dSS1NSQ30gJiYgJHtGSU5EfSAq IC10eXBlIGQgLWV4ZWMgJHtNS0RJUn0gIiR7UFJFRklYfS97fSIgXDsNCgljZCAke1dSS1NSQ30g JiYgJHtGSU5EfSAqICEgLXR5cGUgZCB8ICR7Q1BJT30gLXBtIC1SIHJvb3Q6d2hlZWwgJHtQUkVG SVh9DQouZW5kaWYNCg0KLmlmIGRlZmluZWQoSU5TVEFMTFNfTElOVVhfU0hMSUIpDQpwb3N0LWlu c3RhbGw6IGxpbnV4LXJwbS1wb3N0LWluc3RhbGwNCg0KbGludXgtcnBtLXBvc3QtaW5zdGFsbDoN CglAJHtFQ0hPX0NNRH0gJ0BleGVjICR7TElOVVhfTERDT05GSUd9IDI+L2Rldi9udWxsIHx8ICR7 VFJVRX0nID4+ICR7VE1QUExJU1R9DQoJQCR7RUNIT19DTUR9ICdAdW5leGVjICR7TElOVVhfTERD T05GSUd9IDI+L2Rldi9udWxsIHx8ICR7VFJVRX0nID4+ICR7VE1QUExJU1R9DQouZW5kaWYNCg0K LmlmICF0YXJnZXQocnVuLWxkY29uZmlnKQ0KcnVuLWxkY29uZmlnOg0KLiAgaWYgZGVmaW5lZChJ TlNUQUxMU19MSU5VWF9TSExJQikNCi4gICAgaWYgIWRlZmluZWQoSU5TVEFMTF9BU19VU0VSKQ0K CUAke0VDSE9fTVNHfSAiPT09PiAgIFJ1bm5pbmcgJHtMSU5VWF9MRENPTkZJR30iDQoJJHtMSU5V WF9MRENPTkZJR30NCi4gICAgZWxzZQ0KCUAke0VDSE9fTVNHfSAiPT09PiAgIFJ1bm5pbmcgJHtM SU5VWF9MRENPTkZJR30gKGVycm9ycyBhcmUgaWdub3JlZCkiDQoJLSR7TElOVVhfTERDT05GSUd9 DQouICAgIGVuZGlmDQouICBlbHNlDQoJQCR7RE9fTkFEQX0NCi4gIGVuZGlmDQouZW5kaWYNCg0K bmV3LXBsaXN0Og0KCUAke1JNfSAtcmYgJHtXUktESVJ9Ly5uZXctcGxpc3QNCglAJHtNS0RJUn0g JHtXUktESVJ9Ly5uZXctcGxpc3QNCglAY2QgJHtXUktESVJ9Ly5uZXctcGxpc3QgJiYgXA0KCWZv ciBmIGluICR7RElTVEZJTEVTfTsgZG8gXA0KCQlycG0yY3BpbyAke19ESVNURElSfS8kJGYgfCAk e0NQSU99IC1pZCAtLXF1aWV0OyBcDQoJCSR7RklORH0gKiAhIHR5cGUgZCB8ICR7U09SVH0gPiAk e1BMSVNUfS5uZXc7IFwNCgkJJHtGSU5EfSAtZCAqIC10eXBlIGQgfCAke1NFRH0gLWUgJ3N8XnxA ZGlycm0gfCcgPj4gJHtQTElTVH0ubmV3OyBcDQoJZG9uZQ0KDQouaW5jbHVkZSA8YnNkLnBvcnQu cHJlLm1rPg0KDQouaWYgJHtBUkNIfSA9PSAiYW1kNjQiDQpMSU5VWF9BUkNIPz0JaTM4NgkjIHRo ZSBsaW51eHVsYXRvciBkb2VzIG5vdCB5ZXQgc3VwcG9ydCBhbWQ2NCBjb2RlDQouZWxpZiAke0FS Q0h9ID09ICJwb3dlcnBjIg0KTElOVVhfQVJDSD89CXBwYw0KLmVsc2UNCkxJTlVYX0FSQ0g/PQkk e0FSQ0h9DQouZW5kaWYNCg0KLmluY2x1ZGUgPGJzZC5wb3J0LnBvc3QubWs+DQo= --Multipart=_Fri__2_Dec_2005_16_37_34_+0100_fhSp1jdguMFSR4dJ-- --Signature=_Fri__2_Dec_2005_16_37_34_+0100_Fu2vS5M.Xgt7sLJi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDkGo+yzD7UaO4AGoRAviyAJ9ykLD8qisViHR1mLtw1kN6Rp9WJwCeLMxp RaJ+V+EkPZqB9KB7tUC4Rl8= =7lsU -----END PGP SIGNATURE----- --Signature=_Fri__2_Dec_2005_16_37_34_+0100_Fu2vS5M.Xgt7sLJi--