[crux-devel] CRUX next

Fredrik Rinnestam fredrik at rinnestam.se
Tue Jul 10 17:25:30 UTC 2012


On Tue, Jul 10, 2012 at 06:57:19PM +0200, Juergen Daubert wrote:
> > Yes. Keeping only one "compatibility overlay" repo would simplify things
> > a lot. Currently mesa3d is the only xorg port that needs a specific
> > x86_64 .footprint. I've been reluctant to do anything about this since
> > it would require a new repo for just one port, with the current setup.
> 
> Not sure if we both mean the same here. For me the lib32 repo is only 
> for additional ports that are build for multilib purpose.
> Or in other words everything that is currently in one of the *-multilib 
> repositories and named like *-32.
> 
> If you are talking about a overlay repo for i686, we should name it 
> differently. But one overlay repo for core/opt/xorg would be fine here 
> as well, given that we need one, see c) below.
> 

I think we are but maybe my example wasn't clear enough. I just used
mesa3d to demonstrate the pain working with "many" repos containing a
few ports.

> > 
> > Hmm. I do think i686 deserves a new and up to date release (2.8 or 3.0,
> > whatever). I'm not sure it's fair to all the i686 users to just drop a
> > "sorry, no longer supported" bombshell without prior warning. As it has
> > been for a couple of years now, x86_64 has been "unofficial" and
> > "experimental", possibly scaring people away from x86_64 and to i686.
>
> Yeah, that's all right, but who should do all the work? I got the
> impression that I'm the only maintainer still using i686 for the 
> daily work. After a finally switch to x86_64 I'm no longer able to 
> work on i686, at least not officially. Don't get me wrong, I'm not 
> basically against a all-new 2.8 for i686, but I'm open for suggestion 
> who/how we can do it.

Fair enough :)

> > Atleast we should ask around on the mailinglist if people are ready and
> > ok with us "dropping" i686 in favor of x86_64.
> 
> Sure, such a intrusive change should be announced as soon as possible.
> 
> > I think the future of udev is a bit uncertain at the moment. We are not
> > the only ones that dislike systemd. Staying with a "stable" (182?) udev version
> > might be the best bet for now. If major issues would appear (security
> > etc.) it should be not too hard finding patches since few distros are as
> > up to date with upstream as we are.
> > 
> > Switch to systemd? over my dead body! :)
> > 
> > mdev could work. But you do lose features that one's gotten used to over
> > the years (autoload of modules, xorg, etc). I currently use mdev on my desktop
> > and, although it does the job it's supposed to do, it did feel like
> > stepping backwards in time. It is also possible packages might break
> > during the lifetime of 2.8 (or 3.0). xorg-xf86-input-evdev breaks in
> > recent versions without udev. Perhaps being a bit conservative here and
> > stick with a working udev version is the safest bet?
> 
> Yeah, sticking with udev 182 for now would be the most conservative 
> but good working solution. 
> Btw, Debian and Ubuntu are still using udev 175 ;)

rhel is using 147 or something like that :)

-- 

Fredrik Rinnestam



More information about the crux-devel mailing list