scjet wrote:isn't that why they have "LTS" kernel thingy right ? There's your Arch Server.
Not quite... There are lots of non-seamless updates not related to the kernel. The recent /lib symlink change being a perfect example.
Being the one who started ArchServer, I agree with previous sentiments from Allan regarding our failures. Unfortunately I just did not (and do not) have the time or experience to coordinate it properly. Without the man power we struggled to get the basics done upon which we could lay the rest of the project.
I am still interested in the idea and willing to assist anyone who wants to try again; I did hand the project over to someone else who planned to continue it, but that has not come to fruition.
I know that I do not have the experience, but I certainly have the time and the motivation to pass on the torch. I believe that this a huge gap in the offering of Arch Linux, but no other distro offers the simplicity and beauty of Arch.
]]>isn't that why they have "LTS" kernel thingy right ? There's your Arch Server.
Not quite... There are lots of non-seamless updates not related to the kernel. The recent /lib symlink change being a perfect example.
Being the one who started ArchServer, I agree with previous sentiments from Allan regarding our failures. Unfortunately I just did not (and do not) have the time or experience to coordinate it properly. Without the man power we struggled to get the basics done upon which we could lay the rest of the project.
I am still interested in the idea and willing to assist anyone who wants to try again; I did hand the project over to someone else who planned to continue it, but that has not come to fruition.
]]>But then, we already have all the facilities we need, the only thing is that they(e.g. python24) are in AUR and sometimes not maintained well. I guess what we need to do is systemizing it somehow so that they can be cleanly represented to users.
]]>For me there should be at most an additional [lts] and [lts-testing] and there should be only lts from upstream, not patched by another distro (your "middle stream").
One reason I love arch is that patches by the distro are minimal. I appreciate that a lot. IMHO, once you add packages patched by RH/Ubuntu/whoever, you leave the "Arch Way". Someone said that in a similar thread: Maybe you then really want another distro? Which would be legitimate reason to turn elsewhere. Or you use the AUR ;-)
For me Arch is stable enough. What I am missing is kind of that Gentoo feature to switch between package versions (do they still have that?), just would be nice to ignore MySQL5.5 and stay on (still maintained) 5.1.
]]>Wouldn't it be more "KISSish" (and maybe more resource friendly) to create a "[lts]" repo instead of maintaining a separate arch server distro?
Yes, that's exactly what I suggested. To summarize additional things to consider,
1. Should we take packages from RHEL or ubuntu LTS(middle-stream)?
I think it makes sense. it's not only about additional patches, but also configuration, e.g. http://www.serverwatch.com/tutorials/ar … ations.htm
2. Do we need multiple parallel [lts] repositories? e.g. [RHEL5], [RHEL6],... or [lts2010], [lts2015],...
Probably. Because pacman -Syu shouldn't upgrade the lts packages. e.g. from kernel-lts 2.6 to kernel-lts 3.0
An alternative would be a single [lts] repository and adding version to the package name. e.g. kernel26-lts or kernel-rhel5 . Not sure which will be better, I think the latter approach is more arch-ish and elegant.
3. what are we gonna do with glibc?
Unless we keep/maintain all the packages stable, we need to use the latest glibc from [core] repository, no choice. Although I don't like it much, glibc's backward compatibility will be really reliable. If it is once broken, current archlinux will be screwed anyways.
ok. and how about making a stable package wish list? e.g. kernel, postgre, apache, python, etc... (excluding glibc) this should be the very first step, if we really do something.
p.s. If anyone, is interested in, please express in this thread, it will be greatly helpful to move forward. I'm still not sure we(as the entire community) have enough motivation to begin.
]]>Wouldn't it be more "KISSish" (and maybe more resource friendly) to create a "[lts]" repo instead of maintaining a separate arch server distro? We could put older and still maintained versions of pretty much anything in there: kernel, glib, mysql, php, postgres........ Maybe even the current maintainers would be able to maintain two, three versions of their packages, one in [core]/[extra] and one in [lts].
This would be nice for developers as well, if you have to test and comply to php5.2 or MySQL 5.1 and you still get updates through pacman -Syu. Issues like the glibc builds you would have to avoid by putting hard dependencies on older versions of glibc in [lts].
Please correct me, if I am talking total nonsense.
]]>@satchmosgroove
Nice point, thanks for reminding kernel-lts. I agree that bringing more lts-like upstream(or middle stream from other lts distro) to AUR can be a good starting point. We probably can maintain the list of lts packages recommend for server at https://wiki.archlinux.org/index.php/Co … rver_Guide once it is stabilized.
i.E. MySQL : they maintain older versions and we have already AUR packages. Wouldn't that be basically voting them into extra?
]]>I know this also would require quite some additional manpower and organization, but is maybe the easier approach.
( For people who would like to have a stable secure server, but rolling software to newest versions, I know 2 alternatives: FreeBSD or Debian Stable in Combination with Debian Sid, realized with apt-pinning)
]]>1) lack of manpower
2) lack of focus
#2 really compounded #1. Every new team member had something different that their server needed to do so additional things were added rather than finishing off the core of the distro. If a genuine release had been made, even if it was really minimal in what it supported (e.g. LAMP and nothing more...), I think there would have been more people join the project.
I do like the idea of reducing the manpower requirements by following another distro (e.g. RHEL). An "Arch EL6" would be interesting... And converting a .spec file into a PKGBUILD is fairly simple. The issue would be the requirement of Arch specific stuff - such as the initscripts, mkinitcpio - particularly if you want Arch like feel to the distro beyond using pacman to administer it (and you would or this would be pointless...). That is where a lot of time will need to be spent. Just taking the current Arch packages for those will not work as the require newer userspace tools that whatever distro you choose to base this on would have. But again, stripping these down to the bare minimum just to get the initial release done and then backporting any needed changes from the main Arch codebase later could reduce this burden.
Anyway, I still think this is doable. It just needs a fairly harsh task master, at least for the start, to really focus the development.
]]>