On Wed, Jul 23, 2008 at 10:43:28PM +0200, Dieter Baron wrote: [...] > : 2. Providing binary packages for all the world and its mother. > > : Here I think both pbulk (iow, Joerg) and you are wrong. pkgsrc's > : flexibility is both its greatest asset and its curse. From the > : administrator's point of view, the options framework and the > : support for different versions of PHP, Apache and Python is an > : amazing feature. > > : However, it is also part of the reason why our binary package > : distribution (actually, the lack of a proper one) is pkgsrc's > : greatest weakness. Distributing the results of a bulk build is > : easy, but maintaining a binary distribution over the time is where > : we're not to the level of competitors. > > : A binary packages distribution has to be seen as a whole, with a > : set of default options and settings that are consistent across all > : packages. Red Hat, Debian and whoever else provide you with a > : static binary distribution, because that's the only way they can > : sanely maintain and support it. > > I disagree. The main reason people don't use binary packages is > that they disagree with the default settings; that the tools lack > functionality is only second on the list (at least that is the > impression I got from user's feedback). > > We can do this reasonably well when building from source, and I see > no reason we can't do this just as well when installing from binary > packages. The basic problem of figuring out what to install is the > same. > > Yes, our binary package administration tools suck, and supporting > multiple conflicting variants in one binary package repository > increases the demands on our tools, but the problem is not impossible > to solve. My point wasn't that it is not a desirable feature, nor that it is impossible to do. I just don't think we have, or will have, the resources to *maintain* a distribution over time. In order to get easy binary package updates, not only you need a tool to do that, but you also need the binary packages in time and in shape. I have no doubt that we will eventually get the former, but for the latter, I don't think we can afford to be too ambitious about it. My reading of Cheusov's various comments on the lists is that he treats pkgsrc mainly as a research project. I'm sure that's not accurate, it's merely the impression I have. At some point, though, we have to provide something before thinking of everything we could provide the user. [...] > : The other use of bulk building is for testing purposes, in which > : case your VARIANTS idea could have merit. The problem is, if you > : want to test all building possibilities of a package, you also have > : to test all subsets of the options list from the options framework. > > Actually, building with multiple option settings is on the TODO > list. Not all combinations, just a pre-determined subset (by the > package maintainer). Yes, Joerg pointed me to that. It makes perfect sense, and if you think about it, the same applies for combinations of Apache, PHP and Python. That was essentially my point. > : I'll leave as an exercise to the reader to compute how many times > : mplayer and mencoder would be built if we made pbulk or any other > : bulk building system do all possible options combinations. > > : The point is, if you really want to formalise that part, you'd > : better go all the way, and I really wish you good luck with that. > : As for me, I think pbulk is already exceeding its expectations in > : allowing such possibilities, and while pbulk can do whatever it > : wants in its world, there is no point is pushing that feature into > : pkgsrc. > > I think we should go exactly as far as we want to produce binary > packages, since that is what this is for. Well, what do we want then? :-) -- Quentin Garnier - cube%cubidou.net@localhost - cube%NetBSD.org@localhost "See the look on my face from staying too long in one place [...] every time the morning breaks I know I'm closer to falling" KT Tunstall, Saving My Face, Drastic Fantastic, 2007.
Attachment:
pgp8HMSEFKHrJ.pgp
Description: PGP signature