Re: [crux-devel] CRUX next
On Sat, Jul 14, 2012 at 09:57:14AM +1000, Danny Rawlins wrote: HI Everyone, Here is my reply, thanks for that! [...] 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. If we must have one repo for 32bit compatibility it should be called compat32. But I disagree it's not hard to have coe-32 xorg-32 opt-32 contrib-32 as jaeger has now. What do you mean with hard? From a technical point of view it's not a big issue to have three repos instead of one, but it's an issue. You have to create the repos, add a user group for each repo, manager user for that group etc. But the main point is a different one: IMO most users will _not_ need the multilib feature, therefore the idea is to keep the impact of it as minimal as possible, or better, to move the stuff that is needed for it mostly out of the way. And in this sense having six repos instead of three is a big issue ;) [...] What do you think? Other points to make that x86 (32bit) could be comunity driven so as to not be official but still available for use. Much like Jues i586 was around for a very long time. except more users will hopefully jump on that band wagon. Of course, I've nothing against any contributed solutions. IF we must have a pure 64bit iso then we could have some script to convert it to multilib and add in the additional overlay repo's as required. I'm entirely against a solution that splits our efforts. Our little team should work on one and only one CRUX. Greetings Juergen ___ crux-devel mailing list crux-devel@lists.crux.nu http://lists.crux.nu/mailman/listinfo/crux-devel
Re: [crux-devel] CRUX next
On Fri, Jul 13, 2012 at 04:46:20PM +0200, Juergen Daubert wrote: [...] 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. If we must have one repo for 32bit compatibility it should be called compat32. But I disagree it's not hard to have coe-32 xorg-32 opt-32 contrib-32 as jaeger has now. What do you mean with hard? From a technical point of view it's not a big issue to have three repos instead of one, but it's an issue. You have to create the repos, add a user group for each repo, manager user for that group etc. But the main point is a different one: IMO most users will _not_ need the multilib feature, therefore the idea is to keep the impact of it as minimal as possible, or better, to move the stuff that is needed for it mostly out of the way. And in this sense having six repos instead of three is a big issue ;) s/three/four/ ___ crux-devel mailing list crux-devel@lists.crux.nu http://lists.crux.nu/mailman/listinfo/crux-devel
Re: [crux-devel] CRUX next
On 14/07/12 00:51, Juergen Daubert wrote: On Fri, Jul 13, 2012 at 04:46:20PM +0200, Juergen Daubert wrote: [...] 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. If we must have one repo for 32bit compatibility it should be called compat32. But I disagree it's not hard to have coe-32 xorg-32 opt-32 contrib-32 as jaeger has now. What do you mean with hard? From a technical point of view it's not a big issue to have three repos instead of one, but it's an issue. You have to create the repos, add a user group for each repo, manager user for that group etc. But the main point is a different one: IMO most users will _not_ need the multilib feature, therefore the idea is to keep the impact of it as minimal as possible, or better, to move the stuff that is needed for it mostly out of the way. And in this sense having six repos instead of three is a big issue ;) s/three/four/ ___ crux-devel mailing list crux-devel@lists.crux.nu http://lists.crux.nu/mailman/listinfo/crux-devel Hard meaning not that difficult, but perhaps it would be simpler to have 1 repo to overlay in prt-get.conf far less effort to include 1 instead of 4. ___ crux-devel mailing list crux-devel@lists.crux.nu http://lists.crux.nu/mailman/listinfo/crux-devel
Re: [crux-devel] CRUX next
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
Re: [crux-devel] CRUX next
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. 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? c) Create a final CRUX 2.7.2 for i686 I have no strong opinion on this but it seems like a nice idea. 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. Regards, Matt ___ crux-devel mailing list crux-devel@lists.crux.nu http://lists.crux.nu/mailman/listinfo/crux-devel
Re: [crux-devel] CRUX next
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
___
crux-devel mailing list
crux-devel@lists.crux.nu
http://lists.crux.nu/mailman/listinfo/crux-devel
Re: [crux-devel] CRUX next
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: 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. 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. 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. 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. 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. 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. 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. d) Device management As outlined in another mail [4], the udev sources has been merged into systemd and it's no longer possible to build a standalone udev with minimal dependencies. It is foreseeable that systemd will become a hard dependency for udev soon. What can we do? - stick with udev 182 or try to extract newer versions from systemd even if we had to add stuff like dbus and intltools to our core ports. How long will this work? - switch our init system to systemd - use devtmpfs together with mdev for device managment IMO going with mdev is the most clear and CRUX-ish way [5], but we might run in greater problems in the future, because more stuff will depend on udev/systemd. This is especially true for all kind of desktop software and everything that depends on dbus, *kit and the like. I think the future of udev is a bit
[crux-devel] CRUX next
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. 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. 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. 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. 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. d) Device management As outlined in another mail [4], the udev sources has been merged into systemd and it's no longer possible to build a standalone udev with minimal dependencies. It is foreseeable that systemd will become a hard dependency for udev soon. What can we do? - stick with udev 182 or try to extract newer versions from systemd even if we had to add stuff like dbus and intltools to our core ports. How long will this work? - switch our init system to systemd - use devtmpfs together with mdev for device managment IMO going with mdev is the most clear and CRUX-ish way [5], but we might run in greater problems in the future, because more stuff will depend on udev/systemd. This is especially true for all kind of desktop software and everything that depends on dbus, *kit and the like. What do you think? best regards Juergen [1] http://crux.nu/Wiki/TODO28 [2] One may ask why not doing both alongside, but that is too much work for our little team, at least as a official version. [3] http://crux.nu/Main/History [4] http://article.gmane.org/gmane.linux.distributions.crux.devel/2284 [5] From my personal point of view I was never really happy with udev. The whole development is unpredictable and udev is doing all kind of magic behind my back. ___ crux-devel mailing list crux-devel@lists.crux.nu http://lists.crux.nu/mailman/listinfo/crux-devel
Re: [crux-devel] CRUX next
On Sun, Jul 08, 2012 at 10:28:57AM +0200, 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. 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. 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. 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. 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. 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. Atleast we should ask around on the mailinglist if people are ready and ok with us dropping i686 in favor of x86_64. d) Device management As outlined in another mail [4], the udev sources has been merged into systemd and it's no longer possible to build a standalone udev with minimal dependencies. It is foreseeable that systemd will become a hard dependency for udev soon. What can we do? - stick with udev 182 or try to extract newer versions from systemd even if we had to add stuff like dbus and intltools to our core ports. How long will this work? - switch our init system to systemd - use devtmpfs together with mdev for device managment IMO going with mdev is the most clear and CRUX-ish way [5], but we might run in greater problems in the future, because more stuff will depend on udev/systemd. This is especially true for all kind of desktop software and everything that depends on dbus, *kit and the like. 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? What do you think? I think it's time for a new release! :) best regards Juergen [1] http://crux.nu/Wiki/TODO28 [2] One may ask why not doing both alongside, but that is too much
