[crux-devel] meeting notes & next IRC Meeting

Mark Rosenstand mark at borkware.net
Mon May 29 09:38:17 UTC 2006

On Mon, 2006-05-29 at 09:16 +0200, Johannes Winkelmann wrote:
> - We'll try to push out 2.3 later this year (Q3/Q4) if possible; it'll
>   include at least the following:
>   - Xorg 7.1
>   - gcc 4.1.x (note that I'd consider it safe to update gcc via ports
>     during the 2.2 cycle, but that's up for discussion)
>   - glibc 2.4

Excellent! FWIW I'm running all of those now, and have had few problems
as you know from my reports. To summarize:

Xorg 7.1:
 - None really, thanks to tilman :)

GCC 4.1:
 - slim wouldn't compile out of the box, Johannes fixed it in a couple
   of minutes.
 - Other breakage at that point also applied to 4.0, so the jump will
   be pretty painless.

glibc 2.4:
 - Firefox required a patch from Fedora CVS to compile, fixed
   upstream in
 - Ruby redefines eaccess in intern.h, which is a problem since the new
   glibc changed it a bit. Problem triggered in one of the KOffice 1.5
   betas, workaround was to disable the ruby scripting support.

> - Extend setup to handle modular X; one idea which was discussed and
>   considered viable was to do grouping, such that one could first select
>   the core group, the xorg group, and the [name to be found; remaining
>   packages from opt] group

I'll suggest something like the FreeBSD install set selections, except
for the top-level profiles ("Developer desktop" etc.), so instead of
having all packages in one list, there'd be something like:

[x] core -->
[ ] opt -->
[ ] xorg -->

Space would select/deselect all the packages, Enter would go into a list
similar to the one we have today, listing all the packages in the

>   - The idea of dependency handling during 'setup' was brought up, but
>     not discussed in detail yet [personal remark: easier with
>     dependencies in packages]

Sounds more like 3.0 material IMHO :)

>   - some devs would like to see easier update procedures, to
>     avoid the CD boot/reboot for updates; not discussed in detail
>     either, though interesting and definitely wanted by many 

Hmm, I don't think the reboot is necessary other than for booting a new
kernel. They could just mount their filesystems with --bind to /mnt and
the CD to /mnt/mnt and then do a chroot. Or am I missing something?

> - We'll start the public wiki section as soon as we find a volunteer to
>   look after it (i.e. check the entries from time to time for spam or
>   unwanted stuff).


> - we'll set up ck4up on crux.nu to check core ports; jue has kindly
>   provided a special version and a configuration file

Nice :)

Would it be an idea to integrate ck4up in the ports somehow, e.g.
optionally add a file to each port containing a list of URL's to check?

Then it could be invoked with "ck4up -r /usr/ports/core" - it's
obviously more scalable for all sorts of repositories. Thinking about
it, it's probably also a nice way to check for dead/moved distfiles :)

> In addition, danm proposed the following three feature additions, noting
> that we claim to utilize on using recent libs and tools:
> 1. move /etc/rc.d/net to iproute2
>   The consensus here was that we'll move /etc/rc.d/net to iproute2 for
>   2.3 but keep shipping net-tools

While on the subject, rc.d entries are by default not rejected, but the
net script holds config data. Not a biggie, but a (simple, no extra
config files) solution would be nice.

> 2. use PAM
>   This has to be investigated, it's a tough balance between features and
>   simplicity; integrating CRUX into certain infrastructures can be
>   rather hard without PAM, and the transition seems painful. We need to
>   evaluate the impact of this before deciding

Just a thumbs up from here. As much as we all love simplicity, CRUX is a
general-purpose distro, and PAM is taken for granted by a lot of
software these days.

> 3. install info pages
>   This wasn't all that controversal as it might seem :-). In general, we
>   agree that info pages contain important information at times, and we
>   have to admit that several users would like to have them; we also
>   agree that some consider them junk :-). We to slightly change our
>   position on this, such that:
>   - we move texinfo to core and require maintainers to have it installed
>     (since some packages conditionally install the info pages only if
>     texinfo is there)
>   - we require that packages install their info pages
>   - we extend pkgadd to support hooks such as:
>     INSTALL     ^usr/info/.*$       NO

Great! An extra argument in favour for info pages is that they're used
almost only in the GNU packages, which man pages are extremely sparse
and reference the info files for "more info".

>   Whether 'NO' or 'YES' will be the default here is to be decided, but
>   taking this route makes our packages more flexible without sacrificing
>   a lot. As a personal remark, the same rule should IMO be used for
>   desktop files and icons, i.e. install in general, allow rejection via
>   pkgadd.conf.

I'd suggest to default to YES for all such entries, the reason being
that it's far easier to go from YES to NO than the other way around
("rm -rf /usr/info && sed :^usr/info:d -i /var/lib/pkg/db" versus
reinstalling all packages)

>   If/When we do this, we'll have to (re-)define 'junk' though; some
>   might say that this way, we could just as well install /usr/share/doc
>   and reject it by default, or even translations. Prepare some arguments
>   :-)

README's for Solaris users, INSTALL files (read the port), etc. I'll
stick out of the discussion about the "grey items" though, seems it
could get nasty ;)

More information about the crux-devel mailing list