Babe in the Woods: A Linux User Migrates to FreeBSD (OfB.biz) [LWN.net]

Babe in the Woods: A Linux User Migrates to FreeBSD (OfB.biz)

Posted Oct 11, 2003 5:15 UTC (Sat) by rsidd (subscriber, #2582) [Link]

FreeBSD packages are generally forward compatible: when I went from 4.x to 5.x (a pretty major upgrade), all my 4.x packages still worked. Backward compatibility also exists to some extent: a package for FreeBSD 4.9 is likely to work on older 4.x releases. 5.x packages, however, probably won't work on a 4.x system.

I find it incredibly annoying when a linux package looks for glibc 2.3.2 and refuses to run because I only have 2.3.1 installed. Surely minor versions should remain compatible -- isn't that the point of minor version numbers?

Babe in the Woods: A Linux User Migrates to FreeBSD (OfB.biz)

Posted Oct 11, 2003 6:51 UTC (Sat) by dvdeug (subscriber, #10998) [Link]

If minor versions were 100% compatible in every way, then there would be no point in new versions. While some, probably most, software may be arbitrary in requiring glibc 2.3.2 instead of glibc 2.3.1, there's the possibility of bugs in .1 that would break the program that have been fixed in .2, or new functions in .2 that the program depends on.

Babe in the Woods: A Linux User Migrates to FreeBSD (OfB.biz)

Posted Oct 11, 2003 15:30 UTC (Sat) by rsidd (subscriber, #2582) [Link]

Indeed, the only point of a minor version upgrade (2.3.1->2.3.2) should be
bugfixes. If there aren't any, don't release an upgrade. If there are
new features that break backward compatibility, save them for 2.4.

Babe in the Woods: A Linux User Migrates to FreeBSD (OfB.biz)

Posted Oct 11, 2003 20:10 UTC (Sat) by Ross (subscriber, #4065) [Link]

I disagree. Interfaces should be stable between minor versions. There is
no excuse for not keeping them compatible. Most actual bugs can be
fixed without changing exported function protoypes, structure
definitions, constants, etc. And if the bug can't be fixed that way
they should just bump the major version.

For example, if atoi() returned the wrong value for numbers divisible by 42
fixing it should be binary compatible with existing applications because
it would not involve changing anything visible to those applications. Any
program which somehow relied on it returning the wrong number would be at
fault for depending on a bug. Most compatability problems are from changes
to prototypes, added or removed fields in a structure, or changes in the
sizes of exported types. Those kinds of changes can and should be
avoided in minor releases because they are very likely to break programs
which are standards compliant. Other bug fixes which are transparent from
an interface standpoint are appropriate.

I think that is the distinction that most people make between minor and
major version changes in a library.

Babe in the Woods: A Linux User Migrates to FreeBSD (OfB.biz)

Posted Oct 12, 2003 9:22 UTC (Sun) by mbp (guest, #2737) [Link]

That's all fine, but it's rather off the point of whether it's ever OK to have a package depend on >= 2.3.2 rather than just >=2.3. Clearly, it can be. To take your example, suppose that the broken atoi() means the program simply won't run on 2.3.1. Allowing users to think it's going to run, when in fact they need to upgrade libc, is just going to frustrate the users and produce a lot of pointless bug reports.

Adding new functions in a minor release is not a great idea but sometimes needed.

Babe in the Woods: A Linux User Migrates to FreeBSD (OfB.biz)

Posted Oct 13, 2003 0:24 UTC (Mon) by perlid (guest, #6533) [Link]

As far as I know, glibc i using some kind of symbol versioning, so from version 2.1 and up (I think) they may change some interfaces, and still keep backwards compatibility. So almost any program compiled for glibc 2.1 or higher should work on all newer glibc:s. Of course the opposite is not true, as almost every new glibcversion (even the minor releases) has introduced some new functionality (new functions for example).

Babe in the Woods: A Linux User Migrates to FreeBSD (OfB.biz)

Posted Oct 13, 2003 13:12 UTC (Mon) by metacircles (guest, #8895) [Link]

So almost any program compiled for glibc 2.1 or higher should work on all newer glibc:s.

I wish. Glibc maintainers have been known to make both API and ABI-incompatible changes in patchlevel releases: see e.g. http://mail.gnu.org/archive/html/bug-glibc/2003-08/msg00144.html and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=207806 for one example.

Whether or not you consider these changes were required, it does demonstrate the importance of checking version dependencies thoroughly.

Babe in the Woods: A Linux User Migrates to FreeBSD (OfB.biz)

Posted Oct 11, 2003 5:17 UTC (Sat) by namaseit (guest, #13940) [Link]

I have tried slackware 9.0 about a month ago. Havent looked back since.
Desktop, Laptop, Theatre PC, servers 1-3 all have slackware.

If your gonna use slackware you should know about 'swaret'. a very good
utility to keep pkg's in slackware updated and install new ones. There is
also a global front end called gswaret. No its not a gtk app. There might
not be a pkg for every package to install on slackware, but you can
convert rpm's using rpm2tgz. And as long as you do a full install, you
wont have any dependency problems. Unless its an odd package that has
other deps like mplayer and libdvdcss or something of the like.
And you can find some pkgs from www.linuxpackages.net which has some pkgs
that you dont get from the slackware site.

Babe in the Woods: A Linux User Migrates to FreeBSD (OfB.biz)

Posted Oct 11, 2003 6:28 UTC (Sat) by rloomans (subscriber, #759) [Link]

I used to use RedHat Linux, until I tried Debian three years ago. Haven't looked back. I've been running the unstable distribution with very few problems.

The problems I have had have been nasty (messed up PAM, and stuffed up glibc) that required work with a rescue disk.... but that's why I upgrade my desktop first, server second :)

For me at least, RPM packages are easier to build than Debian packages, but Debian has much more pre-packaged and it is more likely to build from source cleanly.

I have a RedHat Linux desktop at work and it pains me. I can well understand people new to Linux (whether Windows, Mac, BSD or commercial UNIX) being somewhat dissatisfied with RedHat, et al. The quality of third party RPMs is nowhere near the standard of Debian's collection nor the BSD ports.

I'm waiting for some spare time, and I'll install Debian at work.

Babe in the Woods: A Linux User Migrates to FreeBSD (OfB.biz)

Posted Oct 11, 2003 14:35 UTC (Sat) by erat (guest, #21) [Link]

FreeBSD has its own set of annoyances, but compatibility of packages isn't as much of an issue as it is for most Linux distributions. The beauty of FreeBSD is that you have not only the source code to the OS level stuff, but also the "build system". Most (not all) Linux distros give you software pre-packaged and they offer source code to those packages but more often than not they don't supply the complete build system. On FreeBSD, you maintain a complete OS source code tree using cvsup, and whenever you want to rebuild the entire system you change to a certain directory and run "make world". I believe there are simple make commands that'll update installed ports as well, but I could be smokin' something...

I would guess Debian is capable of rebuilding itself, and I know Gentoo (the most FreeBSD- ish of the Linux distros) can do it, so FreeBSD isn't the only game in town. I seriously doubt Red Hat or SuSE offer this, or ever will. The last time I had a Linux system it ran Gentoo, IMHO the best of the Linux distros. I don't use Linux anymore so I can't say if others have advanced to Gentoo's level.

Linux distributions can't rebuild themselves?

Posted Oct 11, 2003 15:20 UTC (Sat) by vonbrand (subscriber, #4458) [Link]

What makes you say Red Hat and other distributions can't build itself, or that but more often than not they don't supply the complete build system? AFAIU, the Red Hat people do build the binary packages under Red Hat. Each time I tried to rebuild a binary package (for a open source package at least) in Red Hat the source RPM was available, and worked fine.

There are also complaints about "dependency hell" and "third party packages". Sure, FreeBSD and Debian solve this. By a very simple trick: there are no third party packages whatsoever. It is either official, or it isn't there.

Linux distributions can't rebuild themselves?

Posted Oct 11, 2003 17:36 UTC (Sat) by ultrotter (subscriber, #7118) [Link]

Are you relly sure there are no unofficial debian packages? I wouldn't say so. Take a look at http://www.apt-get.org, for example... And I know about quite a few unofficial repositories beside the ones listed there, and also of software pages that offer a binary .deb made directly upstream.

Linux distributions can't rebuild themselves?

Posted Oct 11, 2003 17:40 UTC (Sat) by piman (subscriber, #8957) [Link]

The reason there aren't many unofficial Debian packages (there are a few) is because most people who make packages can either find a sponsor or become a DD themselves. I maintained a repository for about a year before I become a DD, but I'm slowly emptying it as I upload them to official servers or give up on the package.

On the other hand, until recently, Red Hat was a closed project; you needed to be in the small group of Red Hat employees to get things packaged.

Linux distributions can't rebuild themselves?

Posted Oct 11, 2003 22:13 UTC (Sat) by erat (guest, #21) [Link]

Re: Red Hat

I'm not talking about providing all the tools necessary to build RPM packages. I'm talking about the system used to build the entire distribution from scratch: bootstrap files including any "skeleton" archives, filesystem heirarchy, "self hosting" build system (i.e. tools are built, then those tools build other packages like glibc, then they're rebuilt, then the rest of the distro is built, etc.), installation tree, on and on... All RPM based distros can (re)build RPM packages. I know of none that can build themselves 100% from scratch from a stock installation like FreeBSD can.

In other words, there's no directory in a stock Red Hat system that I can change to and run "make" to rebuild the entire distro from the ground up. If one exists, do let me know about it. I've been wrong before.