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 1.5.0.2 required a patch from Fedora CVS to compile, fixed upstream in 1.5.0.3. - 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 category.
- 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).
_o/
- 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 ;)