Re: CUPS and AVAHI (bloatware)

[Dumitru Mișu Moldovan]

Ingo Schwarze  wrote:

[…]

> 
> > but it's so damn frustrating when I need to look
> > up some of the differences.  
> 
> On a build slave, i guess you do have the disk space to simply
> install all the -doc packages for the packages you are using?
> Sure, it's one additional step at install time, but certainly
> better than lacking documentation in such a role.
> 
> > And it's a pretty eccentric Linux distro,
> > with quite a lot of peculiarities.  
> 
> I hope you don't count the use of mandoc among those.  :-D


Hi Ingo,

That's cool…  I didn't realize at a time, so I guess mandoc does its job
in Alpine Linux as brilliantly as in OpenBSD.  Congrats!

In regards to installing -doc packages in Alpine, it wasn't such a big
deal once I realized the problem.  Disk space is not an issue on that
build slave either.  I think in retrospect the biggest frustration was
realizing where the missing doc files are.  I don't remember
encountering that on other OS'es / distros, for good reason.



BTW, great little distro, I enjoyed Alpine quite a lot.  And trying to
be security-conscious, I believe immunity through diversity is a thing
in the software world as well.  The more diverse the kernels, C, TLS
libs etc., the better (hurray to standards!).  I wonder if Alpine will
survive in current form the 2017 "privatization" of the (GPL!) grsec
patch, though.  I, for one, have decided to completely switch to OpenBSD
as a direct consequence of it (from Hardened Gentoo).  So far, enjoying
contributing to a more diverse world!  ;-]




pgpItQrJzMuD3.pgp
Description: OpenPGP digital signature

Re: CUPS and AVAHI (bloatware)

[Ingo Schwarze]

Hi Dumitru,

Dumitru Moldovan wrote on Tue, Oct 31, 2017 at 10:58:25AM +0200:
> On 30.10.2017 00:32, Ingo Schwarze wrote:
>> Cag wrote on Sun, Oct 29, 2017 at 09:49:49PM +:

>>> man/info pages, pdf/html docs - in -doc;

>> Over my dead body.  Software without documentation is completely
>> useless, almost a crime.  Docs must always be available, even on
>> a tiny server.  The sysadmin logs into the server, needs a brief
>> look at the docs to fix stuff -- and is slowed down because the
>> docs aren't there, and a web search turns up the wrong version,
>> and a wild goose chase ensues?  No way.

> So true!  I am that sysadmin and have such a system as a build slave
> among many others (~30 combinations of OS / distro / arch).  I
> understand why it is built with docs separated in dedicated packages
> (it's Alpine Linux,

That's actually an interesting distro.  :)

> designed originally for embedded stuff, where disk space really
> counts),

Right.  When you design an operating system for a specific purpose,
some decisions might actually make sense that would be very bad
decisions in a general purpose system like OpenBSD or Debian.

> but it's so damn frustrating when I need to look
> up some of the differences.

On a build slave, i guess you do have the disk space to simply
install all the -doc packages for the packages you are using?
Sure, it's one additional step at install time, but certainly
better than lacking documentation in such a role.

> And it's a pretty eccentric Linux distro,
> with quite a lot of peculiarities.

I hope you don't count the use of mandoc among those.  :-D

Yours,
  Ingo

Re: CUPS and AVAHI (bloatware)

[Dumitru Mișu Moldovan]

On 30.10.2017 00:32, Ingo Schwarze wrote:
> Hi,
> 
> Cag wrote on Sun, Oct 29, 2017 at 09:49:49PM +:
> 
> 
>> man/info pages, pdf/html docs - in -doc;
> 
> Over my dead body.  Software without documentation is completely
> useless, almost a crime.  Docs must always be available, even on
> a tiny server.  The sysadmin logs into the server, needs a brief
> look at the docs to fix stuff -- and is slowed down because the
> docs aren't there, and a web search turns up the wrong version,
> and a wild goose chase ensues?  No way.

So true!  I am that sysadmin and have such a system as a build slave
among many others (~30 combinations of OS / distro / arch).  I
understand why it is built with docs separated in dedicated packages
(it's Alpine Linux, designed originally for embedded stuff, where disk
space really counts), but it's so damn frustrating when I need to look
up some of the differences.  And it's a pretty eccentric Linux distro,
with quite a lot of peculiarities.

[…]



pgp_d2ih4mXM9.pgp
Description: OpenPGP digital signature

Re: CUPS and AVAHI (bloatware)

[Rupert Gallagher]

Patch:

add "--disable-avahi --disable-dbus" to configure.

I hope the package maintainers will consider the opportunity to make their task 
easier, by applying the above and thus removing a shitload of dependencies that 
are both functionally unnecessary and a security hazard.

End-of-thread.

Sent from ProtonMail Mobile

On Thu, Oct 26, 2017 at 1:24 PM, Rupert Gallagher  wrote:

> It is well known that cups does not need avahi.
>
> Avahi is an option, it requires dbus, which requires X11. If you have a 
> server with limited resources and without X11,  you cannot install the 
> present cups package.
>
> Please remove cups's dependency on avahi.

Re: CUPS and AVAHI (bloatware)

[Ingo Schwarze]

Hi,

gwes wrote on Mon, Oct 30, 2017 at 01:43:03AM -0400:

> The last time AVAHI got installed on one of my systems
> the installer started it immediately.
> Avahi then proceeded to scribble on that system's
> network configuration and confuse other systems on
> that subnet.

That doesn't sound like OpenBSD at all.
Did that happen to you on a Debian system?

  schwarze@isnote $ pkg_info | grep avahi
  avahi-0.7p0 framework for Multicast DNS Service Discovery
  schwarze@isnote $ ps axu | grep avahi
  schwarze 45428  0.0  0.0   312  1372 pd  S+p1:37PM0:00.00 grep avahi
  schwarze@isnote $ grep avahi /etc/rc.conf.local
  schwarze@isnote $ grep avahi /usr/ports/print/cups/pkg/cupsd.rc 
  schwarze@isnote $ 

So i have avahi installed, i did not change its configuration,
and it is not running.  Even the cups start script does not appear
to automatically enable it.

I think what you are asking for is already the case.

If you think there is a bug, you need to be more specific.

Yours,
  Ingo

Re: CUPS and AVAHI (bloatware)

[Ingo Schwarze]

Hi,

Rupert Gallagher wrote on Mon, Oct 30, 2017 at 06:11:45AM -0400:

> Ingo, we must not install 100MB of unwanted optional software.
> Since when OpenBSD joined the bandwagon of bloatware?

Since 1995.

Sure, OpenBSD tends to avoid installing stuff that is never needed,
but avoiding to install stuff that may not be needed for a particular
purpose has never been a priority among the project goals.  It has
always been secondary to correctness, usability, simplicity, security,
reliability, and in particular to ease of maintenance.

In many cases, the above goals naturally result in smallness
as a by-product: replacement of ntpd with OpenNTPD, Apache
with httpd, bind with nsd/unbound, groff with mandoc, ...

Yet, smallness of the minimum install is not a goal in itself.
For example, OpenBGPD is part of the base system, and uninstalling
it is not supported.

Also, the above goals do not always result in smallness.
Consider the recent addition of clang.  We call that GNU:
Gigantic and Nasty but Unavoidable.

Yours,
  Ingo

Re: CUPS and AVAHI (bloatware)

[edgar]

 
 
Does ports@ no longer exist?
 
 
 

 
 
 
 
 
>  
> On Oct 30, 2017 at 5:59 AM,wrote:
>  
>  
>  On Mon, Oct 30, 2017 at 06:36:38AM -0400, Rupert Gallagher wrote:  >  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? What is the point 
> of stirring around in the past? That won't change anything. Where is your 
> diff that fixes a problem, today? Venting frustration on this list is not 
> productive and won't solve your problem. Instead, you could be patiently and 
> respectfully discussing technical details of your proposed diff with the 
> package maintainers (provided they're still in the mood for such a discussion 
> after you've derided their work on this list). 
>  
 

Re: CUPS and AVAHI (bloatware)

[Stefan Sperling]

On Mon, Oct 30, 2017 at 06:36:38AM -0400, Rupert Gallagher wrote:
> 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?

What is the point of stirring around in the past?
That won't change anything.

Where is your diff that fixes a problem, today?
Venting frustration on this list is not productive and won't solve
your problem. Instead, you could be patiently and respectfully
discussing technical details of your proposed diff with the package
maintainers (provided they're still in the mood for such a discussion
after you've derided their work on this list).

Re: CUPS and AVAHI (bloatware)

[Stefan Sperling]

On Mon, Oct 30, 2017 at 06:11:45AM -0400, Rupert Gallagher wrote:
> Ingo, we must not install 100MB of unwanted optional software.
> Since when OpenBSD joined the bandwagon of bloatware?

It's happened ever since you chose not to do anything about it.

It's your choice. If you really need to get rid of those extra 100MB
you can figure out what's involved, try to achieve consensus for your
ideas within the community, and get the work done. If consensus for
your ideas cannot be achieved, you can still maintain custom changes
locally and be happy with a system built just as you like it.

Re: CUPS and AVAHI (bloatware)

[Rupert Gallagher]

noth --> both

Sent from ProtonMail Mobile

On Mon, Oct 30, 2017 at 11:36 AM, Rupert Gallagher  wrote:

>> 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 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 acti...@openbsd.org>

Re: CUPS and AVAHI (bloatware)

[Rupert Gallagher]

+1

Sent from ProtonMail Mobile

On Mon, Oct 30, 2017 at 6:43 AM, gwes  wrote:

> The last time AVAHI got installed on one of my systems the installer started 
> it immediately. Avahi then proceeded to scribble on that system's network 
> configuration and confuse other systems on that subnet. I would assert that 
> Avahi should be either (a) not automatically started when installed or (b) 
> split. I am not asking for a general split. This one package causes a lot of 
> confusion if the daemons are started. A simple "do you want to enable the 
> daemons?" would be good enough. Is this worth considering? thanks geoff 
> steckel

Re: CUPS and AVAHI (bloatware)

[Rupert Gallagher]

> 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  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.

Re: CUPS and AVAHI (bloatware)

[Rupert Gallagher]

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  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

Re: CUPS and AVAHI (bloatware)

[gwes]

The last time AVAHI got installed on one of my systems
the installer started it immediately.
Avahi then proceeded to scribble on that system's
network configuration and confuse other systems on
that subnet.

I would assert that Avahi should be either (a)
not automatically started when installed or (b)
split.

I am not asking for a general split. This one
package causes a lot of confusion if the daemons
are started. A simple "do you want to enable the
daemons?" would be good enough.

Is this worth considering?

thanks
geoff steckel

Re: CUPS and AVAHI (bloatware)

[Kurt H Maier]

I don't like the idea of splitting packages, but I get weirded out when
ghostscript (which DOES have a no_x11 variant) winds up pulling in dbus.
I guess there's no escaping freedesktop.org.

khm

Re: CUPS and AVAHI (bloatware)

[Ingo Schwarze]

Hi Cag,

Cag wrote on Sun, Oct 29, 2017 at 10:51:29PM +:
> Ingo Schwarze wrote:
 
>> No.  OpenBSD is a developer-oriented system, so headers are an
>> integral part of the installation.  Installing them must not be
>> optional, or it will cause nothing but needless confusion as soon
>> as people actually start using what they installed.

> And what if someone wants to build an OpenBSD router?

I did so many times.

> It doesn't need headers, or docs.

I did read manual pages there in the past, for sure.
It even happened in 2017 that i read manual pages on a server
machine (that doesn't even have a monitor) and then committed
improvements to that manual based on what i read there.

Besides, i regularly use /usr/include as part of the documentation,
usually more than once every week.  Many manual pages contain copies
of struct declarations, but many others actually point to the header
files for that kind of documentation, and many OpenBSD developers
agree that in some cases, that's a reasonable way to document.

> It doesn't have a lot of storage.

Sure, my first OpenBSD router had 200 MB of hard disk space grand
total.  I did have to do a few special things to save space there,
but the last time i needed that was more than a decade ago.  One
i'm currently still running has a 1 GB disk.  No more special savings
needed, OpenBSD just works out of the box.

Oh, and by the way, the only package i usually install on routers
is this one:

   $ pkg_info -L rsync
  Information for inst:rsync-3.1.2p0

  Files:
  /usr/local/bin/rrsync
  /usr/local/bin/rsync
  /usr/local/man/man1/rsync.1
  /usr/local/man/man5/rsyncd.conf.5
  /usr/local/share/doc/rsync/tech_report.tex
  /etc/rc.d/rsyncd

I guess you don't want to split that into -main and -doc, right?

So the discussion about splitting packages is *particularly*
irrelevant for very small servers because those have hardly any
packages in the first place.

> Are you a dev?

Yes, I am.

> Use this meta -dev package that pulls -dev versions of all packages
> you installed.

Hell, no.  Useless additional work, one more thing to code when
packaging, one more thing to configure, one more thing to maintain,
one more thing to forget about.

> Are you an admin?

Yes, I am.

> Install this -doc metapackage with docs.

Useless additional work.  One among the most important strengths
of OpenBSD is that it requires less work and less configuration.
It just works without any of the additional steps you propose.

I do all the things you want to improve all the time, but don't
see any actual problem that needs solving.

Yours,
  Ingo

Re: CUPS and AVAHI (bloatware)

[Jeremie Courreges-Anglas]

On Sun, Oct 29 2017, Ingo Schwarze  wrote:

[...]

>> /usr/local/share/locale files - in -lang;
>
> In most cases useless on OpenBSD, most of that stuff isn't used 
> in the first place.

Most of what can be found in /usr/local/share/locale are LC_MESSAGES
files handled by gettext, they are actually used as soon as one sets
LC_MESSAGES.

There's a bunch of LC_TIME and LC_SCRIPTS files too, which are unused it
seems.

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: CUPS and AVAHI (bloatware)

[Theo de Raadt]

> > No.  OpenBSD is a developer-oriented system, so headers are an
> > integral part of the installation.  Installing them must not be
> > optional, or it will cause nothing but needless confusion as soon
> > as people actually start using what they installed.
> 
> And what if someone wants to build an OpenBSD router? It doesn't need
> headers, or docs. It doesn't have a lot of storage. Are you a dev?
> Use this meta -dev package that pulls -dev versions of all packages
> you installed. Are you an admin? Install this -doc metapackage with
> docs.

You can use what we provide which satisfies the maximum number of
needs & requiresments in the smallest complete operating system
package...

Or you can go it all yourself.  Why don't you do that?

It is pretty obvious you are only thinking of yourself, so you should
go create your own system.

I actually think you don't have the combination of balls, skills,
or dedication to follow through on anything you are talking about,
so I expect you'll keep using OpenBSD.

But we don't need to put up with your demands.  Adjust your attitude
user -- you didnt pay a dime for the wonderful software built over
25 years by thousands of volunteers.


I believe this conversation is over, because you have no credibility.

Re: CUPS and AVAHI (bloatware)

[Cág]

Ingo Schwarze wrote:

> No.  OpenBSD is a developer-oriented system, so headers are an
> integral part of the installation.  Installing them must not be
> optional, or it will cause nothing but needless confusion as soon
> as people actually start using what they installed.

And what if someone wants to build an OpenBSD router? It doesn't need
headers, or docs. It doesn't have a lot of storage. Are you a dev?
Use this meta -dev package that pulls -dev versions of all packages
you installed. Are you an admin? Install this -doc metapackage with
docs.


Cheers

-- 
caóc

Re: CUPS and AVAHI (bloatware)

[Theo de Raadt]

> > 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.

Re: CUPS and AVAHI (bloatware)

[Cág]

> 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.

> By the way who are you?

A happy fairly long time user.

> 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.

> More complexity.

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 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.

-- 
caóc

Re: CUPS and AVAHI (bloatware)

[Ingo Schwarze]

Hi,

Cag wrote on Sun, Oct 29, 2017 at 09:49:49PM +:

> headers and such - in -dev;

No.  OpenBSD is a developer-oriented system, so headers are an
integral part of the installation.  Installing them must not be
optional, or it will cause nothing but needless confusion as soon
as people actually start using what they installed.

> man/info pages, pdf/html docs - in -doc;

Over my dead body.  Software without documentation is completely
useless, almost a crime.  Docs must always be available, even on
a tiny server.  The sysadmin logs into the server, needs a brief
look at the docs to fix stuff -- and is slowed down because the
docs aren't there, and a web search turns up the wrong version,
and a wild goose chase ensues?  No way.

Yes, there are exceptions.  If the documentation is of excessive
size, in a hostile format like PDF, and/or needs a ridiculous
toolchain for building, then in rare cases separate -doc may be the
least terrible way out, but it's always a symptom that docs are
pitifully defective.

> /usr/local/share/locale files - in -lang;

In most cases useless on OpenBSD, most of that stuff isn't used 
in the first place.  Certainly not important enough to consider
special rules for it.

KISS.

Yours,
  Ingo

Re: CUPS and AVAHI (bloatware)

[Theo de Raadt]

> > Build time of cups isn't really an issue. But the dependency chain 
> > around cups is already very delicate, and anything involving optional
> > dependencies for a library gets *really* awkward further down the chain.
> 
> How about package splitting? cups doesn't require avahi binaries or XML
> dbus entries (org.freedesktop.Avahi.Something.xml), it can only use
> libavahi-client and libavahi-common shared libraries, so let them be in
> avahi-libs or libavahi or whatever. The same applies to dbus packages;
> they're big and fat with a lot of executables, but many programmes only
> need libdbus.so.

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?

By the way who are you?

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?

You come off as pretty uncharitable.

> Since we started the topic, another example: as I am typing this in
> mutt, why would I need the entire cyrus-sasl, if mutt-sasl only needs
> libsasl?

Because decisions were made by some people, to try to satisfy the
most common requirements.

> It's already done by various package managers, some of them are ugly,
> some of them are pretty cool. Most of them split packages into -dev,
> -doc, -lang, and lib-, of course in case of having files that fit
> these categories:
> headers and such - in -dev;
> man/info pages, pdf/html docs - in -doc;
> /usr/local/share/locale files - in -lang;
> shared libs - in lib-.

More complexity.

I don't think you are listening.  The ports developers make economical
decisions as to how things get coupled, because the upstreams keep
changing their minds.  You can seperate things, and a year down the
line that seperation doesn't work anymore.  Then it all has to be redone.

It seems there aren't enough people in the ports tree to satisfy the
complex requirements you describe.

Re: CUPS and AVAHI (bloatware)

[Cág]

Stuart Henderson wrote:

> Build time of cups isn't really an issue. But the dependency chain 
> around cups is already very delicate, and anything involving optional
> dependencies for a library gets *really* awkward further down the chain.

How about package splitting? cups doesn't require avahi binaries or XML
dbus entries (org.freedesktop.Avahi.Something.xml), it can only use
libavahi-client and libavahi-common shared libraries, so let them be in
avahi-libs or libavahi or whatever. The same applies to dbus packages;
they're big and fat with a lot of executables, but many programmes only
need libdbus.so.

Since we started the topic, another example: as I am typing this in
mutt, why would I need the entire cyrus-sasl, if mutt-sasl only needs
libsasl?

It's already done by various package managers, some of them are ugly,
some of them are pretty cool. Most of them split packages into -dev,
-doc, -lang, and lib-, of course in case of having files that fit
these categories:
headers and such - in -dev;
man/info pages, pdf/html docs - in -doc;
/usr/local/share/locale files - in -lang;
shared libs - in lib-.

-- 
caóc

Re: CUPS and AVAHI (bloatware)

[Stuart Henderson]

On 2017-10-29, gwes  wrote:
> 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.

Build time of cups isn't really an issue. But the dependency chain 
around cups is already very delicate, and anything involving optional
dependencies for a library gets *really* awkward further down the chain.

Re: CUPS and AVAHI (bloatware)

[Ingo Schwarze]

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

Re: CUPS and AVAHI (bloatware)

[gwes]

On 10/26/17 07:24, Rupert Gallagher wrote:

It is well known that cups does not need avahi.

Avahi is an option, it requires dbus, which requires X11. If you have a server 
with limited resources and without X11,  you cannot install the present cups 
package.

Please remove cups's dependency on avahi.



Check the FAQs for how to build ports.
It's possible to build a version of cups without avahi.
You would need to do it on a moderately capable system:
any recent laptop or desktop system would suffice.
It must have the same type of CPU as your target system.

I'm not sure I have all the details correct, but this is
what should work.

After setting up your system to build ports from
the instructions in the FAQ:

go to /usr/ports/print/cups and edit Makefile to
remove all mentions of avahi and mdns

make print-build-depends > list_of_dependencies

go through that list and install all of them using
pkg_add. This saves considerable time since the
make will build and install all missing dependencies.

This is the crucial step:
make CONFIGURE_ARGS='--disable-avahi --disable-mdns'

you may have to use 'doas' for this step:
make package
this will create a cups package which can be installed
with pkg_add on the system of your choice.
It -will- install dbus. Removing that is harder.

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. In any case posting
a succinct list of the changes you had to make might
be interesting to some people.


geoff steckel

CUPS and AVAHI (bloatware)

[Rupert Gallagher]

It is well known that cups does not need avahi.

Avahi is an option, it requires dbus, which requires X11. If you have a server 
with limited resources and without X11,  you cannot install the present cups 
package.

Please remove cups's dependency on avahi.