Date: Sun, 15 May 2011 15:59:20 +0000 From: Alexey Dokuchaev <danfe@FreeBSD.org> To: Gerald Pfeifer <gerald@pfeifer.com> Cc: cvs-ports@FreeBSD.org, cvs-all@FreeBSD.org, ports-committers@FreeBSD.org Subject: Re: cvs commit: ports/emulators/wine Makefile distinfo pkg-plist ports/emulators/wine/files patch-dlls-wineoss.drv Message-ID: <20110515155920.GB19328@FreeBSD.org> In-Reply-To: <alpine.LNX.2.00.1105150744430.28608@gerinyyl> References: <201105140021.p4E0LlP7029193@repoman.freebsd.org> <20110514082018.GC97304@FreeBSD.org> <alpine.LNX.2.00.1105150744430.28608@gerinyyl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, May 15, 2011 at 08:08:22AM -0700, Gerald Pfeifer wrote: > On Sat, 14 May 2011, Alexey Dokuchaev wrote: > >> Only tentatively remove $DATADIR/wine upon deinstallation to allow for > >> the forthcoming wine-gecko port > > I've read your reasoning in the PR about the separate gecko-enabled > > port, and while I am generally not very happy about the idea of > > sub-ports, I have to say that it makes sense when slave or sibling ports > > carry substantial amount of extra functionality, heavy dependencies, or > > features that are useful to minority of users. > > One of the biggest weaknesses of the FreeBSD Ports Collection is that, > unlike RPM or DEB based systems, one port cannot easily create a set > of complementary binary packages. Very true. Number of people (me included) pointed out this particular weakness as one of our primary drawbacks when compared to e.g. RPM (other is dependencies fragility, but that is out of scope of this discussion) for number of times in the past. > (Think of -devel and -doc packages as general concepts supported by that.) While I personally think that -devel packages (in the way this suffix is used in Linuxish world) is rather evil than good, I would agree on -doc. > Is anyone looking into this for FreeBSD? No one that I'm aware of. :-( > > In case of wine-gecko, however, making separate port I think is overkill. > > It's just a single .cab file, worth couple of megs, and most users want > > it anyways. I believe OPTION (default to on) is better suited and just > > will DTRT here. > > It increases the size of the package by two thirds. And unless you view > web pages under Wine, this won't be needed, so game players, viewers of > medical applications,... probably won't leverage it. > > In comparison, if you look at Debian or openSUSE, for example, Wine there > is spread over some twenty (sub)packages. Yuck. :-) Scary. Back to the point, however. As I've said, since bundling extra .cab file does not add plethora of extra stuff that user would have to pull as extra dependencies, 2/3 increase of relatively light package seems quite tolerable; in return, we provide single package user can install and forget about it. Carefully selected and reasonable defaults is one of the strong sides of ports (and thus packages) that we offer, despite all aforementioned drawbacks. Whenever I had to use Wine (which is maintained quite nicely by you, BTW) I've always had to lurk out for and fetch this damn .cab. ./danfe
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110515155920.GB19328>