SHORT comment on the end.
> Of course it's up to the developers what goes in, and I can understand > the repeated request for ideas and not comments, but I hope you can also > understand that people might be a bit concerned that the (on the whole) > beautifully simple PKGBUILD scripts might begin to go the way of gentoo > or debian. I am another one who shies away from distributions with > split-off dev-packages, for example. > > I think the first point, building (sensibly) split packages from one > PKGBUILD makes good sense, and can't be too hard to implement, maybe via > a 'subpackages' variable/array or some such. > > But the second point, building with different options (if I understand > it correctly) should be left to separate PKGBUILDs/AUR/etc. It is easy > enough to copy a PKGBUILD and change an option, you could maybe have a > 'tag'/variable used to indicate that something - or even exactly which > bit - needs to be changed in these sibling builds, so that it can be > automated, either outside of makepkg or even as an extra option to > makepkg. OK, that is nearly an idea, but my main plea is to KISS (and > make up). Arch is pretty unique here, please keep it so. > Yep....that *IS* exactly what provides and conflict fields can be used for. And if I remember the discussions correctly that is a large reason why they are there. Very best regards; Bob Finch _______________________________________________ arch mailing list [email protected] http://archlinux.org/mailman/listinfo/arch
