Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 2 Dec 2005 16:37:34 +0100
From:      Jean-Yves Lefort <jylefort@FreeBSD.org>
To:        Alexander Leidinger <Alexander@Leidinger.net>
Cc:        emulation@FreeBSD.org
Subject:   Re: cvs commit: ports/audio/linux-openal bsd.linux.mk
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>

next in thread | previous in thread | raw e-mail | index | archive | help
--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 <Alexander@Leidinger.net> wrote:

> Jean-Yves Lefort <jylefort@FreeBSD.org> 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--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051202163734.23814a2f.jylefort>