meeting notes & next IRC Meeting
Hi there, This is a quick notification to let you know about last friday's meeting, and the upcoming one next wednesday (may 31). Last friday, we mainly discussed issues around 2.3 and random ideas that came up. Here's a brief summary: - 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 - 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 - The idea of dependency handling during 'setup' was brought up, but not discussed in detail yet [personal remark: easier with dependencies in packages] - 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 - We'll review Matt's ISO scripts and merge them into the svn Makefile where appropriate - Cleaning up the package selection; we want to do that, but didn't decide which packages should go or be replaced - 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 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 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 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 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. 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 :-) As a result, we've started a todo list in the wiki: http://crux.nu/Main/ToDo The next IRC meeting will be this coming wednesday, same time (20 CEST). I suggest the following agenda: - Quickly discuss open points from last meeting - discuss 'ToDo', and responsibilities in general - future of pkgutils (especially WRT the INSTALL feature mentioned above) Please post further discussion points in this thread. We'll do futher meetings as needed. Thanks for your attention, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
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 ;)
Hi Mark, On Mon, May 29, 2006 at 11:38:17 +0200, Mark Rosenstand wrote:
On Mon, 2006-05-29 at 09:16 +0200, Johannes Winkelmann wrote: [...]
- 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. Yeah, that sounds pretty much like what I had in mind too.
- 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? It's an interesting idea, although I'm not sure if this solves an actual problem.
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 :) Well, ck4up is stateful, i.e. it won't list a change twice; checking for moved/missing distfiles is a slightly different problem; for this, I'd rather go with something like http://crux.nu/svnweb/CRUX/view/tools/scripts/check_urls
I'll try to remember bringing that up at the next meeting :-). Thanks for your comments, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
On Mon, 29 May 2006 11:38:17 +0200 Mark Rosenstand <mark@borkware.net> wrote:
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.
Wouldn't it be confusing to list xorg as top-level option? We have core, ort and opt/x11 in it... while list it separately. As far as I remember, BSD's have independent Xblah.tgz
- 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?
May be some long-time running server configurations would not like such tricks...
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.
While I like iproute2, shouldn't just shipping it in opt be enough for now? I would also like to see the discussion on services privileges separation, FHS compliance. I used Juergen's ports to make FHS like ports of apache, mysql, vsftpd with opportunity to create separate users for each... It works, so why not? -- Mikhail Kolesnik ICQ: 260259143 IRC: mike_k at freenode/#crux, rusnet/#yalta Jabber: mike_k@jabber.lafox.net NIC handle: MKK83-UANIC
Hi, On Mon, May 29, 2006 at 14:36:28 +0300, Mikhail Kolesnik wrote:
On Mon, 29 May 2006 11:38:17 +0200 Mark Rosenstand <mark@borkware.net> wrote:
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 --> [...] Wouldn't it be confusing to list xorg as top-level option? We have core, ort and opt/x11 in it... while list it separately. As far as I remember, BSD's have independent Xblah.tgz The practical issue here is that 'xorg' stands for 100+ ports, therefore it _must_ be a group. This is why I didn't call it core/opt/xorg in my original mail, I agree it's confusing otherwise. It's an implementation detail, though.
I would also like to see the discussion on services privileges separation, FHS compliance. I used Juergen's ports to make FHS like ports of apache, mysql, vsftpd with opportunity to create separate users for each... It works, so why not? Well, "it works" is a rather weak argument, since "it works" already now. Can you give us any convincing argument why you think CRUX would benefit from (full) FHS compliance?
Regards, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
Hello, Johannes. On Mon, 29 May 2006 14:19:04 +0200 Johannes Winkelmann <jw@smts.ch> wrote:
I would also like to see the discussion on services privileges separation, FHS compliance. I used Juergen's ports to make FHS like ports of apache, mysql, vsftpd with opportunity to create separate users for each... It works, so why not? Well, "it works" is a rather weak argument, since "it works" already now. Can you give us any convincing argument why you think CRUX would benefit from (full) FHS compliance?
It is not hard to follow FHS rules, but ports creation for many software projects would be easier following this way, it also brings some more systematization (and solves ambiguity sometimes too). I can't really see drawbacks here. Other people might have more important reasons to want this, while mine are mostly theoretical. -- Mikhail Kolesnik ICQ: 260259143 IRC: mike_k at freenode/#crux, rusnet/#yalta Jabber: mike_k@jabber.lafox.net NIC handle: MKK83-UANIC
Mark Rosenstand wrote:
- 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 :)
The CRUX Evolution project had a setup like this. They offered groups like X11, Gnome, KDE, Printer support, etc. It was very slick.. altho I'm sure they were using hard-coded or ad-hoc lists to calculate and satisfy deps. -- Jay Dolan jdolan.dyndns.org A: Because it's difficult to read. Q: Why is top-posting bad? A: Top posting. Q: What's the most annoying thing about usenet?
participants (4)
-
Jay Dolan -
Johannes Winkelmann -
Mark Rosenstand -
Mikhail Kolesnik