autoamtic plists (was: Re: cvs commit: ports/audio/linux-openal bsd.linux.mk)

[Alexander Leidinger]

On Fri, 2 Dec 2005 20:04:07 +0100
Jean-Yves Lefort <jylefort at FreeBSD.org> wrote:

> On Fri, 02 Dec 2005 18:06:08 +0100
> Alexander Leidinger <Alexander at Leidinger.net> wrote:
> 
> > >> >> - 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 ports
> > >> 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.
> 
> Shrug. Ok.

Thanks.

> > >> automatic plist generator to write their own plists. It also allows to look
> > >> 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 (ok,
> > 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. Having
> > 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?
> 
> We have already discussed this:
> 
> http://lists.freebsd.org/pipermail/cvs-ports/2005-September/071826.html

And the metadata infrastructure you outlined in this thread isn't here.
So the concerns which are raised in the discussion starting in
http://lists.freebsd.org/pipermail/freebsd-ports/2005-January/019974.html
can't be met.

Since your switch to install-time plist generation would result in
reduced usability of the ports tree, at least for those people which
are able to read a plist or at least how to extract some information
out of it, I ask you again to go the "commit the autogenerated plist"
way in bsd.linuxrpm.mk to respect POLA of those people (BTW: this would
be the majority of people which participated in the thread I started in
January). It doesn't result in much more work (just a "make new-plist")
and provides the same feature while addressing all concerns noted in
"my" thread.

BTW: most of my commits today to the linux-* ports contained changes to
the plist which I autogenerated with the "new-plist" target of
x11-toolkits/linux-gtk. After autogenerating the plist I had to modify
the plist to DTRT. If you can come up with a smarter way of
autogenerating the plist, the work involved until you're be able to
commit a generated plist (after updating the version number of the port
and fetching the distfiles) is negligible.

Bye,
Alexander.

-- 
                   Press every key to continue.

http://www.Leidinger.net                       Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7