Date: Mon, 06 Apr 2009 23:02:24 +0100 From: Chris Whitehouse <cwhiteh@onetel.com> To: Matthew Seaman <m.seaman@infracaninophile.co.uk> Cc: User Questions <freebsd-questions@freebsd.org> Subject: Re: new package system proposal Message-ID: <49DA7BF0.80403@onetel.com> In-Reply-To: <49D789BD.7020103@infracaninophile.co.uk> References: <49D76B02.4060201@onetel.com> <20090404170401.c0f0bce0.freebsd@edvax.de> <49D789BD.7020103@infracaninophile.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Seaman wrote: > Polytropon wrote: >> Compiling applications in general will lead you into one >> main problem: Many ports have different options that need >> to be set at compile time. For a set of n options, 2^n >> packages would be created, if I consider the WITH_SOMETHING >> options only. > >> One example is mplayer. Its various options select which >> codecs to include or if / if not to build with mencoder. >> In regards of different national law, it may even be >> prohibited to include a several codec, so it needs to >> be installed afterwards manually. >> >> Another example is (you mentioned it) OpenOffice. In the >> past, I was happy to do >> >> # pkg_add -r de-openoffice >> >> or something similar. Today, I'm happy that someone put >> a precompiled package of OpenOffice online and announced >> it on the de- mailing list. > > Hmmm... I was thinking about this the other day. There are two > classes of behaviour where OPTIONS functionality could be passed > down to the compiled pkg level. > > The first is where choosing an option /only/ affects the dependency > tree for a package. The phpMyAdmin port I maintain is like this: > by setting OPTIONS you can avoid installing some php modules -- the > phpMyAdmin code automatically detects the presence or absence of > those modules and does the right thing automatically. Adding an > interactive options menu to provide the same functionality when > installing from packages seems to me to be do-able, although I admit > to no great expertise at C programming. However, aside from meta- > ports, this sort of OPTIONS behaviour is probably fairly unusual in > the ports tree. > > The second case is far more common and far more interesting. This is > where toggling an option controls whether some sub-set of files get > installed or not, without any changes to other parts of the port. > Adding different localizations in many programs, or choosing which > out of a set of drivers for different pieces of hardware to install > (eg. in print/ghostscript8) are cases in point. Now, one answer to > providing the full flexibility of such a port when installed via > packages is simply to split up the port into a lot of smaller ports, > which reduces the problem to the previous one of using OPTIONS to > control the dependency tree. The various different php5 modules are > a good example of this sort of approach in practice. The disadvantages > are exploding the number of directories within the ports tree, requiring > maintainers for all of the newly created tiny little ports and generally > increasing the amount of work it takes to maintain everything. > > Now, one way of alleviating some of the the maintenance burden would be > a fairly simple idea I had. At the moment, there's a one-to-one > relationship between port directories in the ports tree and the packages > installed from them. But that doesn't have to be so: why can't typing > 'make install' in a port directory end up installing several different > packages? Seems quite feasible to me to install a number of sub-ports > as one operation. > > One final note: there's a degenerate case of this behaviour for virtually > all ports in the tree. When installing from ports, you can set > 'NOPORTDOCS' and 'NOPORTEXAMPLES' to avoid installing documentation or > examples respectively. When installing from packages you don't get that > capability. Having foo-docs-n.nn.nn and foo-examples-n.nn.nn sub-ports > would give you that. > > cheers, > > Matthew > You've suggested solutions to a couple of Polytropon's objections, thank you. Do you think there is anough mileage in my suggestion to make it worth putting in front of some ports people? What would have to happen to take it forward? I could rewrite the proposal more clearly. I suspect it would be easier to implement than freebsd-update, as a good deal of the infrastructure already exists, and would have similar benefits. To start developing it would require a ports tree and a selection of packages compiled from that ports tree. 7.2 Release is coming up. Maybe the ports tree plus packages from that would be a good place to start. Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49DA7BF0.80403>