Voila le log de la réunion avec les parties où ils présentent leur plan d'une semi rolling distro basée sur arch afin de remplir leur mission de faire un desktop kde stable pour leurs utilisateurs ce qui n'est pas possible par dessus arch rolling qui est trop instable. Un core tiré de arch freezé pendant un an avec par dessus un KDE rolling. Plus une présentation des nouveaux outils ou projets conexes comme les paquets externes.
Au final on obtient quelque chose qu'on peut avoir avec une distro normale, garder sa distro dans une version stable et mettre une source "instable" de KDE pour avoir un KDE backporté de la version suivante, ce qu'ils appellent "rolling". Perso, c'est ce que je fais, et je mets à jour mon KDE tous les jours sans soucis.
Par contre, la différence qui n'est pas évidente à première vue, c'est que le core lui est mis à jour tous les ans au lieu de 6 mois. Donc au final, il a la possiblité d'être plus stable que les distros "6 mois", à condition qu'on puisse le garder et qu'il soit maintenu au delà de ces 6 mois. Ce qui n'est pas évident vu l'esprit "rolling distro" arch et leurs ressources. On verra.
[15:37:47] ok, to start: i think at least some of you have noticed that arch linux is a fine platform for what we want to deliver, but there are some little "annoyances"
[15:37:50] mainly:
[15:37:59] -.so bumps every few weeks
[15:38:25] -the general "freshness"
[15:38:37] -a lot of manual interaction needed (sometimes)
[15:39:14] everyone can see these problems when looking at the forums, _most_ of them are related to updates
[15:40:57] in one sentence: to do what we really want to do, we need a stable platform.
[15:44:01] <drf__> exactly. boom1992, the problem funkyou is trying to address is not the fact that arch is breaking on us, but that the rolling release model of arch is not suitable for what we want to achieve
[15:44:20] drf__: so what do we wnat to archieve? :)
[15:44:26] <drf__> basically
[15:44:30] <drf__> a half-rolling release model
[15:44:53] <drf__> so, having as funkyou said, a stable platform, which would be a "freezed" core
[15:45:04] <drf__> and on the top of that, our packaged kde+dependencies
[15:45:08] <drf__> rolling
[15:45:49] <drf__> to provide a stable system to users, which is exactly what we miss now. updates are breaking stuff and some times you need to do manual intervention
[15:46:04] <drf__> and that's also why ras0ir is here I suppose :)
[15:46:16] <drf__> there is a project called archserver
[15:46:25] <drf__> which is doing almost exactly what I told you
[15:46:46] <drf__> for everyone: http://www.archserver.org/
[15:47:20] <drf__> yes, definitely ras0ir could explain everyone better what archserver is and what they are trying to achieve
[15:47:48] ok let me tell some about archserver
[15:48:20] as you know, a server needs more stable packages compared to the rolling releases
[15:48:57] so we've decided to create a stable one
[15:49:04] stable as in debian or centos etc.
[15:49:30] we are thinking of releasing new versions a periodic basis
[15:49:37] on a*
[15:49:53] until a new release, we only get security patches to packages
[15:50:10] ras0ir: are you taking pkgbuilds an building it or you just using the binaries from arch repos?
[15:50:35] jofko: taking pkgbuilds and build them
[15:50:46] we're not taking binaries from arch repos
[15:52:22] How often does this 'release cycle' happen ?
[15:53:50] djszapi: it's not decided yet, but it'll be one release per year
[15:54:49] we might need to add some newer libs etc if needed on top of that when kde needs it ...
[15:55:57] so far there are 2 ideas:
[15:56:01] do the same like the archserver guys = sync core/extra/etc from arch once in a time and apply only bug-/security-fixes
[15:56:41] or (a small variation): work together with the archserver guys on their [server-core] and use that combined with timed snapshots from arch [extra]
[15:57:53] second sounds better for me since they do it a little longer than we ;) and we can trade code and devs
[15:58:03] <drf__> I favor the second option
[15:58:25] <drf__> of course some packages will diverge (kernel for example) but we already do that
[15:58:40] here is the whole idea: http://chakra-project.org/temp/core.png
[16:00:15] 1. we can strip down the archserver core a little bit, i am down at 155 pkgbuilds for [core]
[16:00:38] 2. the dependencies needed for kde: ~300 packages
[16:01:04] (this is with gtk/wx/tk etc, i guess we can strip that down quite a lot)
[16:02:00] funkyou: we can't? as we're not in sync with arch anymore?
[16:02:26] boom1992: well, thats the main thing: it wont be arch anymore, everything will be at our repos
[16:03:12] <drf__> boom1992: it's much more feasible than what appears - "extra" packages out of kde stuff would be handled in a slightly different way
[16:03:24] <drf__> and it will also be possible to sync with arch binaries
[16:04:05] <drf__> we have a ~year of a stable platform (and with platform I mean kernel 'n stuff)
[16:04:15] <drf__> and on the top of that, everything else rolling
[16:05:03] and the "everything else" wont be much, we will do it for kde only, no gtk, no other gui stuff, just based on Qt
[16:05:16] so we stick for example with kernel 2.6.32 series when arch has 2.6.35 for example
[16:05:17] <drf__> it's really not much more than what we do now
[16:05:32] we just take real control over releases
[16:05:45] <drf__> and if you consider the manpower which gets lost in fixing stuff during updates, you have the exact manpower needed for performing the additional packaging
[16:05:48] and I don't have all the troubles I've now with live-cds
[16:08:52] <drf__> do not make stuff "rolling" for the sake of having it rolling
[16:09:00] <drf__> but make stuff roll if it's feasible
[16:09:12] <drf__> now, suppose for a moment there is a conflict in package xyz
[16:09:18] <drf__> or an update on that breaks the whole kde
[16:09:29] <drf__> simply we don't sync that package any longer
[16:09:36] like X or so
[16:09:40] <drf__> the good thing about kde is that we won't have problems with so versions
[16:09:54] it all boils down to what we want: kde on an all-purpose platform (like arch) or KDE on a platform made for KDE (what we would do)
[16:09:54] <drf__> since we can rely on backends that work with older software (take policykit for example)
[16:10:32] for example I need older aufs2 to get livecd working
[16:10:35] <drf__> of course the goal is to deliver a stable platform, and update whenever possible
[16:10:52] <drf__> and to tailor this for
[16:15:39] "Our goal with Chakra is to provide a operating system for desktops that is easy to use, but still has all the functionality, clarity, power and speediness of a KISS operating system. In the long term, we want to build an operating system based on Arch Linux that meets most requirements desktop users have today, like easy installation of software, graphical system administration, configuring power management on mobile devices or sharing an internet connection."
[16:25:18] <drf__> so basically what I want to tell you is an idea that appears bad and controversial, but I urge you to let me finish before any critics :)
[16:25:40] <drf__> to the point: arch's pacman is no longer suitable for us.
[16:25:45] <drf__> now to the explaination
[16:25:53] <drf__> I know pacman pretty well - I hacked the shit out of it
[16:26:25] <drf__> aqpm "kinda" works, but will never be perfect. The problem with it is that simply libalpm is created to be run on a terminal, in a single-threaded blocking program
[16:26:30] <drf__> not really our use case
[16:26:54] <drf__> however, there is one good thing in all of this: pacman is extremely simple, and creating a clone is a matter of nothing
[16:27:02] <drf__> so basically, what is the idea?
[16:27:12] <drf__> create a "pacman clone" in Qt, with some added goodness
[16:27:27] <drf__> like a real database
[16:27:34] <drf__> (sqlite)
[16:27:47] <drf__> hooks in addition to scriptlets, mimetype associations and stuff
[16:28:40] <drf__> now, after some talks with funkyou, we also found out some stuff about bootstrapping and dependencies
[16:28:44] <drf__> this is the main idea
[16:28:52] <drf__> having a 2-level package manager
[16:29:39] <drf__> a library handling transactions (install, remove, stuff), and one handling sync operations (download, etc). Both would be very small and I already have a somewhat working POC. Guess what, it's smaller than aqpm and it manages to handle arch's packages basically
[16:29:56] <drf__> so we're to the point where still remains the problem of third party software
[16:30:16] <drf__> boom1992 was right: if we want to distribute firefox, but we don't package gtk and gecko, what the hell?
[16:30:25] <drf__> I have a solution for this, and it's called bundle
[16:30:53] <drf__> I'm studying a bundle system (integrated with the package manager) which would also be able to take binaries from arch's packages
[16:31:19] <drf__> so basically we would have third party software handled in a single file representing a filesystem (more or less like mac os)
[16:31:40] <drf__> and handle everything "extragear" this way.
[16:32:07] <drf__> in the bundle system? There's no KISS, but your system stays extremely clean and simple
[16:32:22] <drf__> and I can assure you the code needed for all of this is extremely simple
[16:32:35] <drf__> implementing this stuff seems hard, but it's really not
[16:34:15] drf__: so we need to "unpack" a program every time we run it?
[16:34:28] boom1992: no, we just mount an image i guess :)
[16:34:39] every freakin run
[16:34:41] sucks...
[16:34:48] and remember performance...
[16:36:12] <drf__> boom1992: why? trust me, bundles are just as fast as anything else
[16:36:12] and deps as well
[16:36:22] <drf__> boom1992: no deps, it's a bundle because of that
[16:36:37] drf__: so we go back to windows way to have deps installed like hundreds of times...
[16:36:39] <drf__> it is completely self contained except from system libraries
[16:36:44] we have gtk installed 4 times or wut?
[16:36:45] all the deps goes in the bundle
[16:36:48] <drf__> exactly
[16:36:57] firefox will be one pkg with all needed in it.
[16:37:02] yes so we have gtk installed 4 times for 4 differeent gtk progs
[16:37:12] <drf__> what is -not- present in our repo will go into the bundle
[16:41:04] <drf__> boom1992: ah, and bundles also have a strong plus: security
[16:41:11] <drf__> because everything is sandboxed
[16:40:23] so basically our goal is to get from distrolet -> distro
[16:40:36] yes, for the sake of our mission :)
[17:04:39] <drf__> the whole point is that I'm not saying this things just because I like to reinvent the wheel, and you know it, given what I do in kde
[17:05:00] <drf__> it's just because - if we want to reach the goal we have, we have to do some brave decisions
[^] # Re: Rolling release
Posté par imr . En réponse au journal Chakra se sépare d'Arch. Évalué à 7.
Au final on obtient quelque chose qu'on peut avoir avec une distro normale, garder sa distro dans une version stable et mettre une source "instable" de KDE pour avoir un KDE backporté de la version suivante, ce qu'ils appellent "rolling". Perso, c'est ce que je fais, et je mets à jour mon KDE tous les jours sans soucis.
Par contre, la différence qui n'est pas évidente à première vue, c'est que le core lui est mis à jour tous les ans au lieu de 6 mois. Donc au final, il a la possiblité d'être plus stable que les distros "6 mois", à condition qu'on puisse le garder et qu'il soit maintenu au delà de ces 6 mois. Ce qui n'est pas évident vu l'esprit "rolling distro" arch et leurs ressources. On verra.
[15:37:47] ok, to start: i think at least some of you have noticed that arch linux is a fine platform for what we want to deliver, but there are some little "annoyances"
[15:37:50] mainly:
[15:37:59] -.so bumps every few weeks
[15:38:25] -the general "freshness"
[15:38:37] -a lot of manual interaction needed (sometimes)
[15:39:14] everyone can see these problems when looking at the forums, _most_ of them are related to updates
[15:40:57] in one sentence: to do what we really want to do, we need a stable platform.
[15:44:01] <drf__> exactly. boom1992, the problem funkyou is trying to address is not the fact that arch is breaking on us, but that the rolling release model of arch is not suitable for what we want to achieve
[15:44:20] drf__: so what do we wnat to archieve? :)
[15:44:26] <drf__> basically
[15:44:30] <drf__> a half-rolling release model
[15:44:53] <drf__> so, having as funkyou said, a stable platform, which would be a "freezed" core
[15:45:04] <drf__> and on the top of that, our packaged kde+dependencies
[15:45:08] <drf__> rolling
[15:45:49] <drf__> to provide a stable system to users, which is exactly what we miss now. updates are breaking stuff and some times you need to do manual intervention
[15:46:04] <drf__> and that's also why ras0ir is here I suppose :)
[15:46:16] <drf__> there is a project called archserver
[15:46:25] <drf__> which is doing almost exactly what I told you
[15:46:46] <drf__> for everyone: http://www.archserver.org/
[15:47:20] <drf__> yes, definitely ras0ir could explain everyone better what archserver is and what they are trying to achieve
[15:47:48] ok let me tell some about archserver
[15:48:20] as you know, a server needs more stable packages compared to the rolling releases
[15:48:57] so we've decided to create a stable one
[15:49:04] stable as in debian or centos etc.
[15:49:30] we are thinking of releasing new versions a periodic basis
[15:49:37] on a*
[15:49:53] until a new release, we only get security patches to packages
[15:50:10] ras0ir: are you taking pkgbuilds an building it or you just using the binaries from arch repos?
[15:50:35] jofko: taking pkgbuilds and build them
[15:50:46] we're not taking binaries from arch repos
[15:52:22] How often does this 'release cycle' happen ?
[15:53:50] djszapi: it's not decided yet, but it'll be one release per year
[15:54:49] we might need to add some newer libs etc if needed on top of that when kde needs it ...
[15:55:57] so far there are 2 ideas:
[15:56:01] do the same like the archserver guys = sync core/extra/etc from arch once in a time and apply only bug-/security-fixes
[15:56:41] or (a small variation): work together with the archserver guys on their [server-core] and use that combined with timed snapshots from arch [extra]
[15:57:53] second sounds better for me since they do it a little longer than we ;) and we can trade code and devs
[15:58:03] <drf__> I favor the second option
[15:58:25] <drf__> of course some packages will diverge (kernel for example) but we already do that
[15:58:40] here is the whole idea: http://chakra-project.org/temp/core.png
[16:00:15] 1. we can strip down the archserver core a little bit, i am down at 155 pkgbuilds for [core]
[16:00:38] 2. the dependencies needed for kde: ~300 packages
[16:01:04] (this is with gtk/wx/tk etc, i guess we can strip that down quite a lot)
[16:02:00] funkyou: we can't? as we're not in sync with arch anymore?
[16:02:26] boom1992: well, thats the main thing: it wont be arch anymore, everything will be at our repos
[16:03:12] <drf__> boom1992: it's much more feasible than what appears - "extra" packages out of kde stuff would be handled in a slightly different way
[16:03:24] <drf__> and it will also be possible to sync with arch binaries
[16:04:05] <drf__> we have a ~year of a stable platform (and with platform I mean kernel 'n stuff)
[16:04:15] <drf__> and on the top of that, everything else rolling
[16:05:03] and the "everything else" wont be much, we will do it for kde only, no gtk, no other gui stuff, just based on Qt
[16:05:16] so we stick for example with kernel 2.6.32 series when arch has 2.6.35 for example
[16:05:17] <drf__> it's really not much more than what we do now
[16:05:32] we just take real control over releases
[16:05:45] <drf__> and if you consider the manpower which gets lost in fixing stuff during updates, you have the exact manpower needed for performing the additional packaging
[16:05:48] and I don't have all the troubles I've now with live-cds
[16:08:52] <drf__> do not make stuff "rolling" for the sake of having it rolling
[16:09:00] <drf__> but make stuff roll if it's feasible
[16:09:12] <drf__> now, suppose for a moment there is a conflict in package xyz
[16:09:18] <drf__> or an update on that breaks the whole kde
[16:09:29] <drf__> simply we don't sync that package any longer
[16:09:36] like X or so
[16:09:40] <drf__> the good thing about kde is that we won't have problems with so versions
[16:09:54] it all boils down to what we want: kde on an all-purpose platform (like arch) or KDE on a platform made for KDE (what we would do)
[16:09:54] <drf__> since we can rely on backends that work with older software (take policykit for example)
[16:10:32] for example I need older aufs2 to get livecd working
[16:10:35] <drf__> of course the goal is to deliver a stable platform, and update whenever possible
[16:10:52] <drf__> and to tailor this for
[16:15:39] "Our goal with Chakra is to provide a operating system for desktops that is easy to use, but still has all the functionality, clarity, power and speediness of a KISS operating system. In the long term, we want to build an operating system based on Arch Linux that meets most requirements desktop users have today, like easy installation of software, graphical system administration, configuring power management on mobile devices or sharing an internet connection."
[16:25:18] <drf__> so basically what I want to tell you is an idea that appears bad and controversial, but I urge you to let me finish before any critics :)
[16:25:40] <drf__> to the point: arch's pacman is no longer suitable for us.
[16:25:45] <drf__> now to the explaination
[16:25:53] <drf__> I know pacman pretty well - I hacked the shit out of it
[16:26:25] <drf__> aqpm "kinda" works, but will never be perfect. The problem with it is that simply libalpm is created to be run on a terminal, in a single-threaded blocking program
[16:26:30] <drf__> not really our use case
[16:26:54] <drf__> however, there is one good thing in all of this: pacman is extremely simple, and creating a clone is a matter of nothing
[16:27:02] <drf__> so basically, what is the idea?
[16:27:12] <drf__> create a "pacman clone" in Qt, with some added goodness
[16:27:27] <drf__> like a real database
[16:27:34] <drf__> (sqlite)
[16:27:47] <drf__> hooks in addition to scriptlets, mimetype associations and stuff
[16:28:40] <drf__> now, after some talks with funkyou, we also found out some stuff about bootstrapping and dependencies
[16:28:44] <drf__> this is the main idea
[16:28:52] <drf__> having a 2-level package manager
[16:29:39] <drf__> a library handling transactions (install, remove, stuff), and one handling sync operations (download, etc). Both would be very small and I already have a somewhat working POC. Guess what, it's smaller than aqpm and it manages to handle arch's packages basically
[16:29:56] <drf__> so we're to the point where still remains the problem of third party software
[16:30:16] <drf__> boom1992 was right: if we want to distribute firefox, but we don't package gtk and gecko, what the hell?
[16:30:25] <drf__> I have a solution for this, and it's called bundle
[16:30:53] <drf__> I'm studying a bundle system (integrated with the package manager) which would also be able to take binaries from arch's packages
[16:31:19] <drf__> so basically we would have third party software handled in a single file representing a filesystem (more or less like mac os)
[16:31:40] <drf__> and handle everything "extragear" this way.
[16:32:07] <drf__> in the bundle system? There's no KISS, but your system stays extremely clean and simple
[16:32:22] <drf__> and I can assure you the code needed for all of this is extremely simple
[16:32:35] <drf__> implementing this stuff seems hard, but it's really not
[16:34:15] drf__: so we need to "unpack" a program every time we run it?
[16:34:28] boom1992: no, we just mount an image i guess :)
[16:34:39] every freakin run
[16:34:41] sucks...
[16:34:48] and remember performance...
[16:36:12] <drf__> boom1992: why? trust me, bundles are just as fast as anything else
[16:36:12] and deps as well
[16:36:22] <drf__> boom1992: no deps, it's a bundle because of that
[16:36:37] drf__: so we go back to windows way to have deps installed like hundreds of times...
[16:36:39] <drf__> it is completely self contained except from system libraries
[16:36:44] we have gtk installed 4 times or wut?
[16:36:45] all the deps goes in the bundle
[16:36:48] <drf__> exactly
[16:36:57] firefox will be one pkg with all needed in it.
[16:37:02] yes so we have gtk installed 4 times for 4 differeent gtk progs
[16:37:12] <drf__> what is -not- present in our repo will go into the bundle
[16:41:04] <drf__> boom1992: ah, and bundles also have a strong plus: security
[16:41:11] <drf__> because everything is sandboxed
[16:40:23] so basically our goal is to get from distrolet -> distro
[16:40:36] yes, for the sake of our mission :)
[17:04:39] <drf__> the whole point is that I'm not saying this things just because I like to reinvent the wheel, and you know it, given what I do in kde
[17:05:00] <drf__> it's just because - if we want to reach the goal we have, we have to do some brave decisions