Ingo, we must not install 100MB of unwanted optional software. Since when OpenBSD joined the bandwagon of bloatware?
Sent from ProtonMail Mobile On Sun, Oct 29, 2017 at 9:26 PM, Ingo Schwarze <schwa...@usta.de> wrote: > Hi, gwes wrote on Sun, Oct 29, 2017 at 03:40:48PM -0400: > On 10/26/17 07:24, > Rupert Gallagher wrote: >> If you have a server with limited resources and > without X11, >> you cannot install the present cups package. I can't comment > on CUPS and avahi in particular, but yes, in general, X libraries are > required to work with packages(7). So even on a stunted server, always > install xbase??.tgz, or expect trouble and deal with it without asking for > help or for changes to the system. Disks that can't hold an additional 63 MB > practically no longer exist. > When this works you should probably work with > the ports > group to make this version available. They may not accept > it > because compiling another version of cups on their > build systems would take > too long. Bulk build times are a consideration, but even if build times are > moderate, additional flavours are often rejected because simplicity and > reliability are paramount. Each additional flavour invites additional failure > modes, requires additional testing, and complicates maintenance of dependent > ports. > In any case posting a succinct list of the changes you had to make > > might be interesting to some people. In general, home-brewing a version of a > library package with some dependency removed is a very bad idea. Even if you > do it, don't advertise the details to the world, because it is likely to trap > the unwary, in particular those who understand even less than you what they > are doing, into following you and screwing their systems up. Say you build > custom, non-official flavour L-noD of the library package L that, in the > official ports tree, always depends on the package D. Months later, you > decide to install the application package A that depends on L. If A also > depends on D, the port maintainer probably did *not* register the dependency > on D in LIB_DEPENDS, BUILD_DEPENDS, or RUN_DEPENDS because that's already > implied by the dependency on L. So with your non-official L-noD installed, > any attempt to install A is likely to fail in surprising ways, no matter > whether you try installing it from packages or whether you try to build it > yourself in your own copy of the ports tree. Yours, Ingo
