Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 02 Dec 2005 18:06:08 +0100
From:      Alexander Leidinger <Alexander@Leidinger.net>
To:        Jean-Yves Lefort <jylefort@freebsd.org>
Cc:        ports@freebsd.org
Subject:   autoamtic plists (was: Re: cvs commit: ports/audio/linux-openal bsd.linux.mk)
Message-ID:  <20051202180608.nvo7zkvp1wswkcs0@netchild.homeip.net>
In-Reply-To: <20051202163734.23814a2f.jylefort@FreeBSD.org>
References:  <200511261918.jAQJIp91001719@repoman.freebsd.org> <20051201152026.lxwvpjokc0sw0okc@netchild.homeip.net> <20051202121534.44c2c7be.jylefort@FreeBSD.org> <20051202142827.2s3y42ss8w0o0g0o@netchild.homeip.net> <20051202163734.23814a2f.jylefort@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Jean-Yves Lefort <jylefort@FreeBSD.org> wrote:

Moving to ports, since it's mostly about the generic topic of plist
generation at install time.

Note for the ports crowth: Jean-Yves is proposing an complete automatic
approach for the plist generation (at install time) for a framework for the
linux ports (so only static files, no %%FOOBAR%% fodder in the plist). I
don't object to the automatic generation of the plist, but I want so see th=
e
generated plist committed to the ports tree. Discussion below, feel free to
chime in.

> 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:

Ok, but this doesn't address one of the major concerns which was discussed =
on
ports@, namely that we can't see which files get installed without
downloading the distfile and installing it. See below.

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

Yes, I have some, so please let's not rush here.

> Major changes:
>  - allow to easily disable auto plist by defining NO_AUTOMATIC_PLIST

Can we have it the other way around? Defining AUTOMATIC_PLIST to enable it?
The majority (not only the linux ones) of ports still has a plist and havin=
g
it this way suggests that an automatic plist is the blessed way of the
FreeBSD project. But this is not the case (or I'm not aware of recent
changes to the porters handbook). See below.

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

Ok.

>> >> - 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.
>>
>> I don't think this is good. I think the descr should mention that the po=
rts
>> 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.

It may be obvious for us, but not obvious for others. I like it to be
unambiguos. Let's do it the other way around (POLA): If someone want's to
override it, he can set it to the FreeBSD port description in the port
itself.

>> automatic plist generator to write their own plists. It also allows to l=
ook
>> 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.

This doesn't address the "lookup" and "will-be-installed-by" parts above (o=
k,
they are the same, but...). These are major topics. You can read on ports@
from this week about someone who tries to write an application which does
something like this but has problems because of the automatic plists. Havin=
g
the static plists (auto-generated or by hand) in the tree, also helps in
support requests, since someone with experience just can tell "install port
X" to a newbie, even if he doesn't know anything about the port in question
himself.

So there's demand, and we mostly can satisfy it, but when we go the "all
automatic" way, we can't anymore.

I can understand that with a really good automatic mechanism, there will be
less errors in the plist (specially some like those I produced in the last
two weeks), but we can have the good part of this mechanism and the good
part of plists in the tree just with the "new-plist" target.

Are there any technical arguments which makes it mandatory to use your
version of install-time generated plists instead of my proposal to commit
the automatically generated plist?

Bye,
Alexander.

-- 
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID =3D B0063FE7
http://www.FreeBSD.org     netchild @ FreeBSD.org  : PGP ID =3D 72077137
   13: F=C3=BCr Windows optimiert
          zusammengestellt aus Hardware-Restposten (Kristian K=C3=B6hntopp)





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