Stable tag will be slipped Sunday and release engineering will begin Monday

[Bill Hacker]

0050405140241.GF1443 at xxxxxxxxxxxxxxxxx> <42530abe$0$717$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <200504052232.j35MWID4086845 at xxxxxxxxxxxxxxxxxxxx> <42531b26$0$720$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <42539c07$0$720$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
In-Reply-To: <42539c07$0$720$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 131
Message-ID: <4253c38e$0$718$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
NNTP-Posting-Host: 202.64.125.135
X-Trace: 1112785807 crater_reader.dragonflybsd.org 718 202.64.125.135
Xref: crater_reader.dragonflybsd.org dragonfly.users:2773

Michel Talon wrote:
> Bill Hacker wrote:
> 
> 
> 
>> Finding a way to select, then focus on keeping current, only about 
>> 500 or so of the 12,000 - odd ports could sure ease the burden.
>> 
>> 
> 
> 
> This is the best way to completely kill any project. A major asset of
>  FreeBSD and Debian is the 12 000 ports tree. It is because you have
>  the choice of running whatever pleases you that you run Debian or 
> FreeBSD and not a ports impaired system like some other secure BSD or
>  some well known commercial Linux distribution.

I'm not suggestign that they 'go away'.  I am suggesting that a
most 'commonly needed' sub-set be given elevated attention - a
committment or priority, if you will, secondary only to 'core'.

There are too many folks whinging about what isn't 'perfect'
and too few available to fix all of it at once - if at all.

> You want to run exim, i want to run postfix and another guy wants to
>  run sendmail,

All those and probably nearly every MTA of note, plus all the spam and
virus, POP and IMAP, webmailer, etc. would certainly be on any list I
made up. Likewise many httpds, databases, sysutils, editors.

All fertile ground, all with lots of users, contributors, followers,
active mailing lists of their own, large communities of interest.

These are not the problem!

But browse the ports tree and note how very many ultra-specialized,
duplicative and stale items are in there.

I say leave most of those in the hands of the specialized communities
that created and use them.
High "body count" of ports that are largely a distraction is not a good
goal.

In many cases there is not even ONE developer/porter to be found
with the time or inclination to invest in keeping these up to date.

> it is the great force of the major Linux or BSD distributions that 
> you can do it easily.

It is the *gift*, if you will, of thousands of volunteers, and one
must keep more than one door open for contributions if that is
to continue.

The *N*X differences are well-known enough and the POSIX
influence sufficiently pervasive, that it is reasonably practical
to develop such that the tarballs and config can be built on any
*BSD or Linux with minimal adjustment.

But 'minimal' is non-zero.  You want a free cabin, you should learn
how to use hammer and nails.

I don't just build from original source tarballs 'coz the ports
are stale or flawed.  I build from tarball because many apps
don't *need* porting.  Less work, not more.

When a developer is considerate and professonal and
attentive enough to *N*X diversity to work that way, it makes
life easier for all concerned - developers, port builders,
port users, package builders, and package users alike.

And all are working off the same code-base, not patches
atop patches atop kludges.....  etc.

*There* is your goal!

- That more developers build a 'universal' source tarball.
Once that is done the rest is far easier to keep up.

> Matt is perfectly right that a new generation ports system should be
>  able to tolerate several versions of the same software.

Matt, and to an even greater extent, we older folk, are *accustomed to*
environments where multiple side-by-side versions are normal.

UNIX - or more accurately - the way C libs have been used and abused,
- is decades behind that particular power curve.
We do indeed need to catch up!

> In the interim, i am just suggesting that the ayatollah technique of
>  axing old libraries when you install a new version is *the* major if
>  not unique cause of the troubles people have encountered with
> FreeBSD (i don't speak about DragonflyBSD on purpose).
> 

"An ounce of prevention"....

It has very rarely been a problem for me - partly because
I tend to have a look at the dependencies and libs listed on the ports
web page, in the port, or in the Makefile trees *before* just turning it
loose, then hunt down problems and alter symlinks, etc.

. ...and because lib and app developers actually *do*
succeed more often than not in delivering a smooth
upgrade path and reasonable legacy support.

Even when one hits a bump, doing a 'make deinstall distclean' followed by
a 'make install' of the *previous version* (the one that had been
working last!) will usually get back all the appropriate libs and
dependencies without need to sit an exam on rocketry. Note that
many ports - especially those known-problematic, carry one or
more previous releases for several years.

'fresh' installs have never been as much of a problem as upgrades, 'coz
nothing is yet using them. If these break, either fix them, or go down
the hall two doors and use a similar app that works with less hassle.

Finally - the habit of *always* compiling from source (never bothered
with packages before DragonFly) means fewer problems with libs anyway. A
binary built with an older lib may fail to find and use the newer one,
but the same source compiled against the newer lib may be happy as a
clam with it.  Package users might miss that and go solving a problem
that those who compile hadn't even seen as a problem.
- and that resilience has been one of the *BSD's great strengths vs
a binary-distro world.  Stuff adapts to change better.

YOMD, but there ain't no silver-bullet or 'one size fits all' anywhere 
in F/OSS-land,
only sustainable alternatives.

Bill