![](https://secure.gravatar.com/avatar/5fbfdcc9fece431e1ca05e46e42255d6.jpg?s=120&d=mm&r=g)
On Wed, Jul 11, 2012 at 08:06:07AM -0500, Matt Housh wrote:
On 07/08/12 03:28, Juergen Daubert wrote:
Hello,
now that glibc 2.16 is available a new version of CRUX seems to be doable. But before we start working, we should consider some important, upcoming changes besides the usual small updates and improvements [1].
a) Switch our main development platform to the x86_64 architecture [2], the first version should be called CRUX 3.0.
I am, unsurprisingly, all for switching to x86_64 as well as multilib. Installing glibc-32 as the only "out of the box" 32-bit package is how the unofficial ISO currently works so that's perfect for me.
b) Keep our repository layout as simple as possible
At the moment we have official repos for i686 and overlay repos for x86_64 and multilib on top of those. That's ok and the best way to do it at the moment, but not really neat for the final solution. I'd suggest to merge everything needed by a) into our core/opt/xorg repos and add only _one_ additional repo, probably called 'lib32', for the compatibility libraries.
Personally I'd prefer to keep the collection separation intact for 32-bit ports, something like 'core-32/opt-32/xorg-32'. With that said I'll go with the majority opinion here, it's just my personal preference. I feel like a single 'lib32' collection could be messy.
Why? The reason for the different repos are more a question of access privileges and in case of core what we define as "important, installation required". In fact xorg is something we could easily integrate into opt. The name of a port must be unique over all repos, so actually it dosn't matter in which repo it lives. IMO the main advantage for one 'lib32' or 'compat32' over '{core,opt,xorg}-32' is easy administration and a simpler repo layout.
As an aside I'd suggest a different name than 'lib32' since there's no guarantee that only libs will be installed from it. Perhaps something like 'compat32' or similar?
Yeah, 'compat32' sounds good to me as well.
c) Create a final CRUX 2.7.2 for i686
I have no strong opinion on this but it seems like a nice idea.
Looks like most maintainers are for a final i686 version, without a clear decision either towards a 2.7.2 or to a all-new 2.8.
d) Device management
Staying with udev 182 seems like the best current option to me. If we cannot separate future versions of udev from systemd then my second preference would be mdev.
Nice, everyone has the same opinion here. Let's stick with udev 182 for now. regards Juergen