Re: Stable tag will be slipped Sunday and release engineering wi
Rahul Siddharthan wrote:
>> - Of close-on 12,000 ports (packaged or not) there are probably
>> fewer than fifty that "really, really, matter".
>>
>> - *which fifty* varies by whom you ask, and even their needs vary
>> from one project, client, server or day of week to another.
>
>
> Try installing GNOME? Or KDE? Both of those "really, really
> matter." KDE alone brings the number to about 70 (using pkgsrc), by
> my count.
For desktops, of course, But neither have any use on a
'real' servers, which are 'headless', nowhere easily viewed by a human,
have neither need of nor resources to waste on X, nor any defensible
reason to carry the security risks.
And - for most of the life of *BSD servers are where it has lived.
Sun, SGI, and HP workstations have had GUI's for a long time,
but for most others it has been the exception, not the rule.
>
>
>> - the vast majority of the source code is witten and maintained by
>> folks who are either inactive, sporadically active, not
>> specifically targeting the *BSDs, or any/all of the above.
>>
>> Which leads to depending on a large and diverse number of
>> volunteers, each maintaining one or several ports in which they
>> have both an interest, and the necessary expertise.
>
>
> Which already exists for FreeBSD, and I suppose for pkgsrc too.
> David Rhodus and friends seem to have a good job with pkgsrc on DFly,
> though there are huge holes still. It would just be nice to pool
> those resources. One bottleneck with the FreeBSD ports system is
> that every patch has to wait for a committer to be committed. Their
> gnats DB is full of uncommitted ports patches. It would be nice to
> figure out some way about that. Again, I think it should be possible
> to learn from Debian: all their packages are contributed by
> volunteers too.
>
Debian has certainly concentrated on, and done a credible job, with
their apt-get. But the only way it looks better than the *BSD's is if you
rate it purely on convenience, and not on being 'current', useful,
or in sync with the original code developers.
Debian marches to the beat of its own *orchestra* not just a different
drummer. If that's what one is used to, it might not be apparent,
but check the Exim mailing lists, just to name one.
Until about a month ago, the Exim package was *three years*
out of date - and Exim is Debian's default MTA.
Exim has - just recently - been brought 'almost current'
- but only in Debian 'unstable'. Worse - the Debian environment
breaks Exim configuration *so badly* that Exim folks had to send
Debian'ers off to set up their own variant of a support list.
No one can understand what Debian config does, or why they
feel a need to break what wasn't broken.
> If it is possible to build GNOME and KDE out of the box, that should
> take care of 95% of the remaining software. And a lot of the other
> build errors may be quite trivial to fix, if there's a build box
> generating new packages each time there's a change in the ports or
> pkgsrc tree.
>
>
Recently, the X environment and gtk with either GNOME (2.8) or Xfce4
*only* install reliably for me from pkgsrc. Trivial or not, the fixes
are a moving target, and a nuisance to fix, 'coz the don't *stay* fixed.
>> If any of the *BSD's were to try to bring this whole area 'in from
>> the cold' and put it under a formal process, they would probably
>> have to drop the number of supported items to 10% of the current
>> 'body count'.
>
>
> IMO, pkgsrc is already a huge improvement over ports, without being
> uncomfortably different. If the other BSDs would just adopt it, it
> would be a big gain for everyone.
>
> Rahul
They are actually different faces of the same animal - a step
beyond Original source code tarball from the developer.
PORT: Successive builds with troubleshooting that lets a port
mantainer figure out what patches are needed to (at least)
guide things into expected *BSD locations, find libs, emplace
configuration and startup scripts, and/or correct a few other
things (via sed inplace, patches, scripts, etc.)
So the port usually a carries with it a pre-built or pre 'biased' configure
file, scripts, patches.
PACKAGE: Either from a port, or by similar process from the original
developer's (not necessarily BSD'ish) tarball - build and package
'generic' binaries with pre-built dependencies and install scripts.
The difference? Cutting out essential, but lower-level 'helpers':
- the 'Port' is a script to fetch *sources*, patch and compile on-box,
- the 'package' is a script to fetch compressed pre-compiled binaries and
install and configure them on-box.
The packages are faster to install, 'coz one is just unpacking, not
compiling, and are closer to 'guaranteed to work' if all that is needed
is ' the road well traveled'.
The ports tree is more convenient than hunting down each developer's
home site, and an easier starting point (usually) for modifications one
needs to do in source, even where developers do a very good job of
making source auto-detect *BSD and auto-configure (as many have done).
Even if both were *perfect*, neither 'port' nor 'package' goes away
just because the other 'exists'. Both retain specific advantages.
Use whichever is best suited for *your* use of any given app - neither
will be 'best fit' for all apps all the time.
And many will *still* be best done from *neither* port nor package, but from
latest developer's tarball if you need fixes or features.
exim and courier-mta nearly always so, just to name two.
Bill Hacker
討論串 (同標題文章)
完整討論串 (本文為第 21 之 49 篇)：