NetBSD-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: ports
On 9/11/2012 10:50, Aleksej Saushev wrote:
John Marino<netbsd%marino.st@localhost> writes:
Pkgsrc has some warts for sure, and I'd like to see substandard
packages deleted rather than following "as long as it builds I'm
sure this crap will be useful to somebody" policy, but pkgsrc
basically does what it was designed to do. I don't think it's
awful or embarrassing.
I strongly oppose this boyscoutish "delete anything that causes problems
to (one or few) developers" attitude. People use computers to do their work,
not because they want to use computers. Sometimes users prefer using old
software that is well-known to them rather than invest time into something new.
I said, "crap", not "old". There's a difference. I'm talking about
substandard packages that are not generally useful and probably never
were. Right now a single voice can halt the removal of a package, but I
don't think pkgsrc should be a personal repository.
Trying to only use pkgsrc-trunk and upgrading binary packages as
you go can lead to failure. Even rolling-replace has to be
restarted a lot for various reasons. So building from source
from an always current trunk is a much worse experience than
you'd find on FreeBSD where that's common practice. However I
think the basic response is "pkgsrc wasn't designed for that"
and there may be some truth to that statement.
My experience with FreeBSD ports is exactly the opposite.
If your position is pkgsrc is better than FreeBSD ports for rebuilding
packages from source in place, I can not even entertain a debate on
that. Fine, you had a bad experience on FreeBSD ports. Maybe you did
something wrong.
In any case, anyone using non-stable branch should be prepared to deal
with problems. This is generic requirement, it doesn't apply to pkgsrc
or NetBSD only.
On FreeBSD, they don't have quarterly branches so by this definition the
ports are always "unstable". This should indicate FreeBSD ports are
better suited for upgrading in place.
As for pkg_rolling-replace, I tried it several times, and found it
rather unstable way to update installed software. If there's someone who
has got satisfactory results, I would like to hear how they accomplished that.
Personally, I'm not prepared to use pkg_rolling-replace for production,
I advise using pkg_chk instead.
I will take a look at pkg_chk. There are several package tools I'm not
familiar with, this is one of them.
John
Home |
Main Index |
Thread Index |
Old Index