[CrackMonkey]softdep urls

[Mike Goldman]

Miles Nordin wrote:

> It's actually a
> tremendous undertaking. NetBSD categorically rejected CVSup because there
> was no way in hell to get M3 running on all the (almost 30) NetBSD ports,
> and giving some ports officially-condoned second-class access to the
> repository was considered philosophically disasterous. so, there _are_
> CVSup servers for NetBSD, but they are mirrors outside the netbsd.org
> domain.  Well, you don't care about all that.  The point is, your job is a
> big one.

Yes, it is.  And I put the project on hold for awhile, until some license
issues could be worked out with Compaq (nee Digital).  I want to do a major
reworking of the build procedure, either before or after the Linux Alpha
port, but certainly before I attempt Linux PPC.  Yes, I am
*adding* platforms, not just building.

> I hope you'll consider getting it integrated as a gcc-current frontend
> when you're done, so that the M3 guys don't drop any more CPU's.

Agreed, if possible.  Now that the license issues are resolved, this may be a
lot easier to accomplish.  m3cc (the compiler) is now under GPL (instead of
DEC's weirdo license).

> Considering that Chill and Fortran 77 and some old Java hack are in there,
> M3 should be a shoe-in.  But, whatever works out.  I s'pect Maxwell could
> really use some competent help, even if it is from a Linux user who's
> going to HELL when he dies.

Maybe my FreeBSD systems will get me consigned to purgatory, at least.

> There's a real problem with M3, not so much because it sucks, as because
> there aren't statistically enough people interested in it as ordinary
> developers, that you end up with the sorts of ultra M3 studs you need to
> do compiler development.  I mean, look how many C users there are, and
> then at how many people there are who know enough to improve gcc.  It's
> rather intimidating.  so, M3 folk end up either,

Right -- M3 needs to be linkable with C.  This is more do-able than is the
case with, say, Oberon-2.  In M3 one can declare modules unsafe, and thus not
use garbage collection and other funky un-C-like stuff.

Javur is largely based on M3, btw.  But it sucks more.

Been thinking about transforming Component Pascal with M3-unsafeness into a
Pythonesque dialect, and calling it Oolong.  Long-term project, probably
never get done.

> The NetBSD packages collection is supposed to be considerably more

> advanced and more featureful compared to the FreeBSD system--it's a lot
> more maintainable and does it's job better.  I've never used the FreeBSD
> system, but this is one of the things the NetBSD folk brag about
> consistently, and that's saying a lot as one of the NetBSD Project's
> biggest problem is a failure to brag often and publicly enough.
>
> But, you probably don't care about that.  It has the same feel as the
> FreeBSD system, yes, definitely.

I do care about that, indeed.

> I've never used dpkg--I used RPM.  FWIW, I was heartily turned off by the
> packages system at first, but not for long.  It didn't take long for me to
> realize how hopelessly _stupid_ RPM is.  There are all kinds of problems
> with it.  and, to be perfectly frank, it really doesn't get much easier
> than

> $ cd /usr/pkgsrc/type-o-stuff/thing-i-want
> $ make install

Agreed.  And RPM is horrible.  But Joey Hess has already gone into some
detail on this.

The problem is not installing a package (port), but *upgrading*.

Let's say you have installed foobar v1.2.  A new version is released, which
fixes some horrible security bug, and you want to replace it with foobar
1.3.  Now what?

On Debian, assuming you're doing the binary-thing, you just do "apt-get
upgrade" but you don't care about that.  Instead, you can instead pull down
the foobar_1.3.orig.tar.gz, foobar_1.3-1.diff.gz and foobar_1.3-1.dsc, run
"dpkg-source -x  foobar_1.3-1.dsc", cd into foobar-1.3 and run "debuild -us
-uc" to build, then "debi" to install.  Done.  Not quite as purdy as "make
install", but it's very routine.  Unfortunately, it does not *yet* do source
dependencies, so *BSD wins some points.

But here's the big difference.  On Debian, your old configuration files for
foobar_1.2 will be maintained or upgraded as appropriate, the foobar_1.3
package installed in its place will *just work*.

On *BSD, you have to manually pkg_delete the foobar_1.2 (making sure to find
and preserve configuration files first), then do the make install,
reintegrade the configuration files (making sure to upgrade them while
preserving any required changes as necessary), then restart the daemon if
appropriate.  This sucks.

> This will download, extract, patch, build, and install the thing-you-want,
> as well as downloading and installing any libraries or build tools (like
> GNU make or Perl or elisp for example) it needs to build thing-i-want.
> When you come back, you'll damn sure have the Thing-You-Want.  You may
> also have Perl and rpm2cpio and Python and emacs and gmake and autoconf
> and UMB-scheme and libtool and glib and libgsm and libgl along with it,
> but you _will_ have what you asked for.

Right.  Debian does something similar (in a binary way) with apt.  Running
"apt-get install foobar" will automatically download and install all
dependencies first.  RPM just sucks.

> You can even type 'make install' as an ordinary user, and the package
> system will _prompt_ you for the root password when it's time to actually
> install.  You can ^C at this point, and restart the build/install without
> losing work.

Can't do this on FreeBSD, I think.  But that's cool.

> If you think it might be worth a second look, you could read about the
> packages system on the NetBSD features page
>
>   http://www.netbsd.org/Misc/features.html
>
> and then move on to the packages system manual in
>
>   ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-current/pkgsrc/Packages.txt
>
> and see if things do or don't seem potentially as sane and happy as I seem
> to be claiming.

I'll take a look.

> BTW, have you used the BSD makefile stuff?  It puts the GNU stuff to
> shame.

Yeah.  It's nice, especially as by configuring a mk.conf you can set system
build-parameters which may be different from that which would otherwise be
used by default.  Nothing really prevents us from using pmake to build
packages on Debian, but most use GNU make (or gmake as FreeBSD calls it).

> Anyway, I can say pretty confidently that serious BSD folk couldn't give a
> goose turd about your fancy little dpkg toys.

Then they have their heads up their asses.  Just because BSD does some things
really well (better, I agree, than any Linux distro, including Debian), does
not mean they have a monopoly on Doing The Right Thing.  And dpkg is a
definite example of The Right Thing.  Crappy pkg_* is not.

> But hey--when they do have something, you can bet it's going to be done
> right. There's already pth, pth-current, unproven-pthreads, and lwp from
> the Coda project in the devel packages category, so there is at least a
> Will where tangible progress is somewhat lacking. We'll see how it goes.
> I hope they do the Masuda/Inohara thing, but I doubt they will.  Someone
> brought up Solaris binary compatibility, which means Scheduler
> Activations.  I am so sick of binary compatibility.

I'm so glad to know that sometime in the year 2030, when all that great shit
I wanted back around the turn of the millennium will show up, it will have
been done right!