On Wed, Jul 11, 2012 at 05:14:10PM +0200, Jose V Beneyto wrote:
> Hello,
>
> sorry for the delay, I had a peak work these days and I could not answer
> before
>
> On 07/10/12 18:57, Juergen Daubert wrote:
> >On Sun, Jul 08, 2012 at 04:29:40PM +0200, Fredrik Rinnestam wrote:
> >>On Sun, Jul 08, 2012 at 10:28:57AM +0200, Juergen Daubert wrote:
> >>>[...]
> >>>
> >>>a) Switch our main development platform to the x86_64 architecture [2],
> >>> the first version should be called CRUX 3.0.
> >>>
> >>>At the time Per Liden had created CRUX, the i686 processor on base of
> >>>the 32-bit Intel IA-32 architecture was state of the art and therefore
> >>>chosen by him as the default optimization for CRUX. But nowadays, over
> >>>10 years later [2], the i686 arch is more or less obsolete, at least
> >>>for desktop machines. The 64-bit extension to the x86 instruction set,
> >>>mostly called x86_64, is the the new standard now.
> >>>
> >>>We had extensive discussions on IRC about the type of system we want,
> >>>a pure 64-bit or a multilib system.
>
> I'm running purelib64 in 2 boxes without any problem, and so far I have not
> found
> any impediment for the daily work, anyways I'm open to multilib and I'd be
> happy
> to work with it long as they have advantages.
> >>>The main consensus is that we ship a "multilib ready" system, but
> >>>without the 32-bit compatibility libraries except for glibc-32. The
> >>>reason for this exceptions is the gcc compiler, which needs the
> >>>glibc-32 at build- but not at run-time.
>
> I'm not as familiar as you with multilib, so can someone point a link or
> information about the problem with gcc compiler and glibc32 at buildtime?
> On the other hand, what would be the impact for a port maintainer? [2]
It's simple, if you configure gcc with --enable-multilib you need both
versions of glibc, 64- and 32-bit, installed.
>
> Well, there's something I have really clear, and I like. If we finally switch
> to a 64bit system, it must be transparent to the user and have native
> libraries
> in /lib, /usr/lib, ... as it has always been.
> I have another 64-bit systems at office and for what I see the one used in
> rhel/fedora/centos and in the FHS is that the /lib/ directory (and /usr/lib/)
> is for 32-bit libraries, and 64-bit libraries go in /lib64 (and /usr/lib64/).
> Debian uses /lib/ for 64-bit libraries, and puts 32-bit in *lib32.
That's our layout too, 'normal' stuff goes into /lib resp. /usr/lib and
the compatibility libararies into /lib32 and /usr/lib32.
> >>Unsurprising I fully support a change in direction towards x86_64. I
> >>also would prefer to ship a stripped down x86_64 only version on the ISO
> >>but with the option to simply add multilib binaries if one chooses to do
> >>so. shipping glibc-32 is a good compromise.
>
> +1
> >>
> >>>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.
> >>
> >>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.
>
> Well lib32 repo or whatever be called means that we would make our life
> easier.
> That means we should avoid being redundant, right?
Sorry, not sure what you mean. If you start using a multilib system you
need the one or another library besides the 64- in a 32-bit version too.
The ports for the 32-bit versions, e.g. zlib-32 and gtk-32, are both
placed into the lib32 or compat32 repository, and not into core-32 and
opt-32 if we follow my suggestion.
> Overlays could be an alternative, but what about our current git
> repos/branches
> organization? should we move {core,opt,xorg,contrib}.git to *-32 names too?
No, don't mix up different arch versions (i686 and x86_64) and the
_additional_ stuff you need for a running multilib system.
Keep in mind that the 'normal' not-multilib user will never touch
the additional compat repository.
> or maybe we can start to merge changes from *-x86_64 repos to new 3.x
> branches?
> whats the plan and ideas?
Yep, that's the plan if we switch our official version to x86_64.
Everything that's now in the *-86_64 will be merged into our
core/opt/xorg repos, the *-x86_64 repos are no longer needed afterwards.
> Maybe I'm wrong, but there are many things to do and since we're a small team
> [2]
> we must study well the next steps.
It's not that much if we do it the simple way, as described above.
> >>
> >>>c) Create a final CRUX 2.7.2 for i686
> >>>
> >>>TBH I'm unsure if we should do that, but it would be a nice service
> >>>for all people using CRUX on older hardware and might be the basis
> >>>for contributed i686 ISOs in the future. IMO updated xorg stuff is
> >>>a must-have for such a version, however, as the version number 2.7.2
> >>>suggests, I wouldn't change the toolchain.
> >>>The main idea behind is to have a final mostly up-to-date system with
> >>>a very solid toolchain for the 'old' architecture.
> >>
> >>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.
>
> I'm still using i686 for the daily work and IMO a new CRUX 2.7.2 would be
> fine.
> Same toolchain + udev 182 sounds like a good inflection point that marks the
> end
> of an era, but I don't wanna close the door to future situations related to
> i686.
> ATM around 70% of the systems I'm running are only i686 capable and I think
> that
> there are still many people like me out there.
Well, one idea might be to create and maintain _one_ new overlay repo
for the i686 arch for a limited time, let's say 1 year or so.
But I'd give that a 'unofficial' status, like x86_64 has currently.
> >>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.
>
> Also we could make an online poll (doodle.com, etc.) and/or we can recover
> the idea
> of IRC meetings.
Let's try to clarify the main things within this thread. If we all have
a clear picture how everything should go we can do a 'casual' meeting
too.
best regards
Juergen
_______________________________________________
crux-devel mailing list
crux-devel@lists.crux.nu
http://lists.crux.nu/mailman/listinfo/crux-devel
