NetBSD Packages Collection Freeze

jschauma writes "Starting Monday, October 6th, 2003, the NetBSD Packages Collection will be frozen in order to stabilize pkgsrc on the various supported platforms. As Alistair Crooks explains in his message to the tech-pkg mailing list, this freeze is done so that the pkgsrc team can shake out bugs, fix broken packages and close pkgsrc related problem reports. If you want to help out, you can take a look at the PR database and submit patches."

Comments

Bulk builds

[BrookHarty]

eliminating all "broken" packages - a "broken" package is one that
does not build, install or de-install cleanly (as determined by bulk
builds on NetBSD/i386)..

Anyone have any details on this Bulk Builds? Is this like FreeBSD bento automated builds?

Re:Bulk builds

[MavEtJu]

For your information, Mark Linimon has made a website which extracts information from the bento logs and the PR database to make a better overview on the error reporting.

it's here

Re:Bulk builds

[leitz]

A "bulk build" is a fairly automated thing where NetBSD builds *all* packages in a sane order. For example, if package X needs package Y, it knows to go build Y before X. Pretty cool stuff, better than some dependency checking things I've seen.

It isn't "automated" in that it starts itself, but once you manually start it it does all the work for you.

Re:Bulk builds

[jschauma]

You can find some more details at http://www.netbsd.org/Documentation/pkgsrc/binary. html. The nice thing is, they are quite configurable, so that you can run a bulk-build with xpkgwedge (to ensure that even X11 programs do not end up outside of /usr/pkg (or whatever your PREFIX is)) or with gcc-3 (if your OS or Port has not yet been switched to use gcc3 as the default system compiler) etc.

The bulk builds are run regularly on different ports, and the resulting binary packages are then uploaded to the ftp sites.

Re:Bulk builds

[Cheesy Fool]

At least they have USE flags so that you can enable/disable features of a package.

Re:Bulk builds

[Bert64]

How about for packages which are inappropriate for i386? surely there are some architecture specific packages which don`t make sense on i386..

Re:Bulk builds

[LizardKing]

A pkgsrc Makefile can specify which architectures and version of operating system the package is suitable for. It can also force the use of a specific version of gcc as well (the DDD package had this restriction fo a while recently).

Chris

gcc 3

[ChristTrekker]

Will they be working on getting everything to compile with gcc 3 while they're at it?

Re:gcc 3

[jmmv]

gcc3 is not the default compiler in the NetBSD 1.6.x branch; therefore, it's not a goal for the pkgsrc branch to work cleanly with gcc3, AFAICT. Even though, -current was switched recently to gcc 3, so it will surely be a goal for the next major release. Anyway, all fixes done during the freeze WRT this will get into the pkgsrc branch, but not all packages will be fixed to work with gcc3.

Although unfortunate...

[agent dero]

I see this as another victory for OSS, by doing something like this we ensure functional software, thanks to the NetBSD team for keeping everything in working order.

Now for those *BSD trolls, this is why *BSD is alive and well, people still use, and are dedicated to producing the *BSDs

Re:Hope they change a few things first...

[saintlupus]

This article on the recent vulnerability refers to "make replace" as "experimental". Have you successfully used it in situations like this?

(I've never seen it mentioned anywhere before -- if it can actually replace stuff in-line like it sounds like, that would be heaven.)

--saint

Re:Hope they change a few things first...

[abs0]

pkgviews should make upgrading a lot less painful. A paper on an early version is at:

http://ftp.lug.udel.edu/pub/NetBSD/misc/agc/pkgvie ws.pdf

Personally I have a pkgchk.conf shared between all my boxes so I knw what should be (re)installed at any point :)

If you can read nroff: cvsweb entry for pkg_chk.8

Re:Hope they change a few things first...

[jschauma]

Yes, it can replace stuff in-line. But you better be aware of the side-effects. If the ABI of a given library has changed, ``make replace'' will really really mess up your system. This is, obviously, not a limitation within pkgsrc, but simply in the way shared libraries work.

However, if you're sure that all dependencies will be able to deal with the new package (say a shlib minor version bump, in theory at least, should not break other packages), then ``make replace'' can save you a lot of time rebuilding dependencies.