Date: Sun, 04 Dec 2005 20:00:46 -0500 From: Adam Weinberger <adamw@FreeBSD.org> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: ports@freebsd.org Subject: Re: Proposal for an additional (sub)section in the porters handbook Message-ID: <4393913E.3020902@FreeBSD.org> In-Reply-To: <20051204151945.29aae42d@Magellan.Leidinger.net> References: <20051204151945.29aae42d@Magellan.Leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Alexander Leidinger wrote: > based upon the consensus (of the absolute majority of participants > which consisted of a lot of committers and some users) in the discussion > which starts with > http://lists.freebsd.org/pipermail/freebsd-ports/2005-January/019974.html, > I wrote the attached proposal for the porters handbook. > > Comments please. This is political rhetoric, not a collection of helpful suggestions. You have too much "thou shalt not" in there, and it looks more like a collection of arguments for removing the plist generating code from bsd.port.mk. > ------------------------------------------------------------------------ > > Install-time vs. commit-time plist These are not phrases that porters use. The PH is not the place to introduce personal monikers. > ---------------------------------- > > > Definition "static plist": a static plist is a plist which does not contain <ref "7.1 Changing pkg-plist based on make variables">plist variables</ref>. > > Definition "dynamic plist": a dynamic plist is a plist which contains <ref "7.1 Changing pkg-plist based on make variables">plist variables</ref>. > > Definition "install-time plist": an install-time plist is a plist which is automatically generated at the time a port is installed. > > Definition "commit-time plist": a commit-time plist is a plist which is included in the CVS reposirory (either as a seperate file or as PLIST_FILES and PLIST_DIRS variables in the Makefile of the port). It may be a static or a dynamic plist. It may also be manually written or automatically generated. These names make no sense to me whatsoever. Either a plist is automatically generated or it isn't. First of all, nobody should be discouraged from using variables in the plist. In fact, the PH says that people SHOULD use variables, e.g. %%DATADIR%%, etc. So, I would advise not differentiating between your "static plist" and your "dynamic plist." What you call an "install-time" plist is what the rest of us call a "dynamic plist." And the "commit-time" category makes absolutely no sense to me whatsoever. There is no part of a port framework that ISN'T in CVS, so I fail to see what that category will accomplish except to confuse people. It sure has me baffled. If you're going to add anything to the PH -- and I don't think you should -- you should narrow it down just to static and dynamic plists, and you should use the typical usage of "dynamic plist". > Some maintainers prefer to use install-time plists. While the use of them is not forbitten, maintainers have to use commit-time plists wherever possible. See, as soon as you use "have to", you've negated any purpose of your addition past political rhetoric. The entire thing could be shortened down to, "Please use static plists when possible, as it enables users to grep(1) through available plists to discover, for example, which port installs a certain file." > Exceptions are complex ports where the plist changes a lot based upon optional features of the port and getting the dynamic plist right would result in a major headache or ports which change the plist based upon the version of BUILD_DEPENDS used (e.g. ports which generate docs with Javadoc). > Ports where it is possible to use a static commit-time plist have to use a commit-time plist. This feels wrong. Nobody *has* to use share/portname in their plist if they choose to use %%DATADIR%%. Using variables cuts down on the amount of bulk in CVS; the GNOME team uses it all the time for things like evolution, where changing one line in the Makefile saves changing hundreds of lines in the plist. > Maintainers which prefer install-time plists are encouraged to add a new target to their port which generates the plist, so that they can enjoy the benefit of an install-time plist (automatic generation of the plist) while the benefits of a commit-time plists are preserved. You seem to be running under the assumption that people only use dynamic plists because they're lazy and don't feel like making a plist themselves. > Benefits of commit-time plists: > - Allows to search for files which are not installed. Affects users. > - Allows to determine if a particular port contains what we want. Affects users. > - Allows to check just with grep if two ports install conflicting files. Affects users (which debug a problem) and developers (which process a bug report). > - Allows to check the plist for flaws/pitfalls with portlint. Affects developers. > - Allows to answer some classes of support requests without the need to install the port. Affects "support frontliners". > - Allows to notice files which are not build but should be build. Affects users (quality of the port/package) and developers (automatic bug notification by the ports build cluster). > - Allows to have a look at the history of what a port installs. Affects users (which have a problem and need support with an old version of a port). About half of those say the exact same thing. Please refer back to the one-sentence example I gave above. > Drawback of commit-time plists: an install-time plist is generated when the port is installed while a commit-time plists needs to be transfered to the user. In addition to containing a spelling error, that's pretty similar to reminding a user that cats and better than dogs because dogs are dogs. I'm not trying to imply that your arguments are invalid, because they most certainly are valid. My point is that to have them in the PH won't accomplish anything productive. > Counter argument to the drawback of commit-time plists: while there are still some locations with limited connectivity where this may matter, the size of the rest of the ports tree combined with only transfering differences (if this results in smaller sizes) and compression (as done by cvsup and portsnap), the additional size of commit-time plists is negligible. This sounds like you mulling over an idea in your head. Again, this sort of thing won't benefit anybody by being in the PH. I advise that you just say, "Dynamic plists can be solutions to problems that static plists cannot solve, but please do not abuse them. They exist to make things possible, not to allow you to skip a step of the porting process." # Adam -- Adam Weinberger adamw@magnesium.net || adamw@FreeBSD.org adamw@vectors.cx || adamw@gnome.org http://www.vectors.cx It's not stupid. It's "advanced." -- Almighty Tallest
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4393913E.3020902>