> On Saturday 19 October 2002 10:42 pm, you wrote:
> [[ shouldn't this be on tech-pkg despite the fact you're approaching
> the issue from the point of view of a NetBSD/sparc user? ]]
>
> [ On Saturday, October 19, 2002 at 11:59:52 (+0100), Andrew Grillet
> wrote: ]
>
> > Subject: pkgsrc
> >
> > Am I alone in thinking that pkgsrc is a fine concept, but in need
> > of being partitioned.
> >
> > As an owner of older Sparcs, with limited size HDs, I for one would
> > like to see pkgsrc split into at least two, and perhaps 3  -
>
> I'm not sure that's practical (i.e. actually splitting pkgsrc into
> multiple parts), though perhaps with just a simple set of
> configuration flags much of it could be handled transparently
> internatlly.

Part of the problem is the sheer size of pkgsrc. (Can you say "out of 
Inodes"). I would like to have a smaller pkgsrc package, by excluding
stuff that its easy to predict would not be useful on my system.
>
> > textmode apps that will run on almost all architectures
> >
> > apps that require X - since they are normally large and
> > require fast hardware (compared to a 25MHx ipc. anyway).
> > Maybe this aught to be "require graphics mode".
> >
> > apps that are really only x86 - or PCI or something else
> > that effectively rules out operation on the majority of
> > architectures.
>
> Indeed there are some packages which have X11 as an option (i.e. they
> have some X11 tool that's not necessarily part of their core
> functionality).  Some are already handled by offering separate
> package modules which build without the X11 feature, but I'm sure
> more could be handled this way too.  (eg. I just submitted a PR for
> catdoc to show that it can be built and be useful without TCL/Tk and
> thus without X11)
>
> Alternately having one /etc/mk.conf flag that simply turned off the
> use of X11 in those packages might be a lot easier than trying to
> figure out what package variant one should use to avoid the necessity
> for X11 stuff.
>
> I think I rambled about this kind of configuration choice on tech-pkg
> just the other day too! ;-)
>
> > I would also like to see a global flag HAS_AUDIO in make.conf
> > such that if it is not set, apps like KDE do not include masses
> > of dependencies on audio software. None of my PCs have
> > working audio, and I cant see this being fixed in the forseable
> > future.  The audio in my Suns may work, but I have never tried it!
>
> This is more or less what I was rambling about on tech-pkg the other
> day.  I think turning audio support off completely should just be one
> of the options on a more flexible control flag that lets you choose
> the type of audio support to be applied across the board, eg.
> "esound" vs. "nas", vs. "dev" (for direct /dev/audio), etc. and
> turning it right off would just be "none".
>
> (that does beg the question of what "none" should do for a package
> that's specifically and only an audio app.  Should it just cause a
> warning to be printed and then build with whatever default makes the
> most sense for that package on that NetBSD port?)
>
It should print a message "building this package is incompatible with
audio option "none"" and exit. If you have a need to build it,
you use 
>make IGNORE_KERNEL_OPTION=YES
os some similarly obtuse flag (or maybe a well named and clear one!)

> > I see no need need for audio on Firewalls, fileservers,
> > nameservers
>
> well if it has a loud enough speaker you can use audio capability so
> that your IDS can shout verbal warnings when the firewall is under
> apparent attack!  ;-)
You mean <sound of axe crashing through plasterboard wall>
>
> > or any computer used in a work environment.
>
> If co-workers might be annoyed by noisy computers then those who want
> their noise^H^H^H^Hsounds can/should wear headphones.
I think its better for ecveryone if they get on with their work
instead of listening to bbc news or hip-hop. Above all, donn't
have them doing those useless CBT courses.

Andrew