> being critical of decisions made > You don't get to make the decisions, since you aren't doing the work
I can do the work. As a matter of fact, I build my servers from scratch, from the firmware all the way up to the automatic configuration of clients. It is hell, but I get what I need, and nothing more. Since I speak out of experience, I know well that cups dependency on avahi is noth a needless burden and a security hazard. The openbsd decision to make cups package dependent from avahi is opaque. Where can we read this decision? What is the evidence that supported it? Is this evidence still relevant? Why, oh why, the package maintainer(s) of cups resist the opportunity to make their own burden less heavy by removing needless parts? Are they on avahi's payroll? RG Sent from ProtonMail Mobile On Sun, Oct 29, 2017 at 11:49 PM, Theo de Raadt <dera...@openbsd.org> wrote: >> > So basically you are saying the ports developers, who have worked very > > >> > hard, haven't built things exactly the way you want. > > Did I get that >> > right? > > Nobody apparently cared about it (neither do I really). It's an >> > idea to > be discussed (or not), not a proposal to have an answer right >> > now. Shrug. > > By the way who are you? > > A happy fairly long time user. >> > They keep using. But your mails are going beyond by being critical of >> > decisions made. > > Are you proposing to write a diff which handles all >> > the cases, or > > are you offloading a proposal on other people -- a >> > proposal you came > > up with in the last hour or so? > > A couple of >> > years ago or so, it doesn't matter. It was discussed > privately and in >> > some forums/lists; and it wasn't me who came up with > this idea first, >> > certainly. I discussed world peace in a bar once. > If would literally >> > take a couple of if's in Makefile for a price of > A LOT of saved >> > bandwidth and disk space. Of course it would quadruple > the number of >> > packages. You don't get to make the decisions, since you aren't doing the >> > work. > > You can seperate things, and a year down the line that >> > seperation > > doesn't work anymore. Then it all has to be redone. > > >> > This can happen with a build system, then it used CMake, now it uses > >> > ninja. Or then it relied on GTK+2, now it uses GTK+3. Or Qt. Or Tk. > Or >> > previous ./configure no longer exist. Lots of words. No action.
