You are not logged in.
http://kmandla.wordpress.com/2008/01/05 … ch-branch/
A stable Arch branch?
Don't look now, but it could become a reality. A thread here describes the rationale for a snapshot of Arch at periodic intervals, allowing users to bounce between stable points, rather than use Arch in the rolling fashion it has now. A wiki page is up and running now too.What would it do? It would make it possible to rely on Arch the same way you would rely on Ubuntu, Debian or other periodic releases — install a release edition, and upgrade to the next after six months or so.
If you're not familiar with Arch, the system now relies on only one release — the current editions of all the software. Every few days — or every day, or every hour if you like — you synchronize against the freshest package list, and your system is updated to the current versions. Old programs are replaced and gone.
Personally it's not something I would use. I like the rolling release over the periodic style just because it gives me quicker updates and bug fixes. It does occasionally backfire, since a quirky package that slips through testing can sometimes get installed. But that's exceedingly rare, and in general, I prefer a rolling style.
But I'd agree that it's great the Arch community is taking the initiative to improve upon it. I would certainly give it a chance, if it comes to fruition.
Offline
kernel 2.6.16.xx has one big issue: kernel developers started to ship well maintained linux-headers from 2.6.18.xx on. before you had to deal with buggy linux-libc-headers.
if you want it stable why stay with the linux kernel?
Offline
At the risk of being a "pill" I'd like to make a brief comment.
I have been using Arch on my production systems for 2 years now and I have to say that either I'm very lucky or my "computer's godmother" is very skilled because I have, virtually never, had my system die because of upgrades.
I had once an issue with nvidia drivers but I just downgraded to the previous working one and I was happy again.
The rolling release has, so far, been painless to me.
Now, I appreciate that that's not everybody's experience but downgrading is a "built in feature", and if people are aware of it; would not that, in itself, make up for the stability discussed in this thread?
Sure, it means people will have to keep packages from upgrade to upgrade (in case a roll-back was needed) but that's a small price to pay to make sure your system will continue to run.
Again, I use my systems for business and I depend on them to make a living but I find Arch to be stable and trust wordy... good work devs !!
So ... perhaps it would be easier to have a "stable" section for the absolutes required by a functional OS: video, networking, the last known stable kernel, and pushing it a bit; audio. That would reduce the efforts on a stable branch to just a hand-full of packages. That also would ensure that any system would, at any given time, be able to run and if some of our favorite packages, outside of the stable group, fails ... there is always back-rolling.
R.
Last edited by ralvez (2008-01-06 00:57:09)
Offline
Personally, I like the way Arch works now, but I also realize that an upgrade can make my system non-bootable, so I try to mitigate things by keeping a separate home partition for my files and performing backups. (Even when running "stable" systems, there are risks when performing upgrades.)
All that said, if this gets off the ground, I will happily help test it.
Last edited by Agent69 (2008-01-06 05:11:33)
Offline
I think a good way to do it would be have some method of "pinning" certain updates to packages as security fixes. Then we can add an option to pacman to only update a package if it is pinned as a security fix.
The benefit of this would be that we wouldn't have to work at making other repositories and such. It would just involve adding a feature to pacman and an option on the pkgbuilds that allows the package maintainer to specify if the package is a security update, a bugfix, or a new version from upstream.
It wouldn't be much more of a hassle for the maintainer to edit this when they are updating a package. Then there would be an option in /etc/pacman.conf to allow the user to specify the types of upgrades that they want. This method saves man power and server space, because we would just be making use of resources that already exist.
I think this is more in keeping with the KISS philosophy, rather than maintaining a repository and essentially forking arch, we just have to maintain some code in pacman.
What do you all think?
Last edited by ihavenoname (2008-01-06 08:03:31)
In this land of the pain the sane lose not knowing they were part of the game.
~LP
Offline
you could always mix and match between a stable and standard Arch packages, unless there were .so version differences, or in very few cases, version dependency. The kernel for example, could easily be used from a 'stable' Arch without difficulty.
ihavenoname: That's a far more complicated setup, and requires a lot of 'internal' work, pacman, developer scripts, etc. Further more, it requires "official" interest. I'm not pushing for this to be "official" Arch, I'm curious to see how well it'll work.
I don't think it'll need a "full" fork either. At first, you pacman .conf could just include [core-solid] [core] [extra]... etc. -- If the package in [core] is stable or the same as would be in [core-solid], then there's no real reason to duplicate that work.
Offline
Does this project aims at creating a stable "snapshot" which gets updated every few months (backports and security fixes excluded)? I think a better decision would be to do as this guy (http://beranger.org/index.php?page=diar … nd-of-linu) suggests: keeping the same base (glibc, desktop environments...) but update end-user applications (firefox blender etc) and of course add security fixes.
This last option is seldom used in GNU/Linux distributions (Pardus is close to it but still updates quite often) but it deserves some thinking; after all in a workstation environment you don't really care what version KDE/Gnome is, just as long as it works. Everyday applications are however more important.
Offline
I think a good way to do it would be have some method of "pinning" certain updates to packages as security fixes. Then we can add an option to pacman to only update a package if it is pinned as a security fix.
This has been proposed on the wiki page; the use of scripts to holdpkg or ignorepkg within pacman.conf.
Offline
1st downloads a pacman.conf file. Anything that I don't want updated is put on hold
from the wiki
HoldPkg = package ...
If a user tries to --remove a package that's listed in HoldPkg,
pacman will ask for confirmation before proceeding.
from the man pages
NoUpgrade = file ...
All files listed with a NoUpgrade directive will never be
touched during a package install/upgrade. Do not include the
leading slash when specifying files.
a better solution? from the sounds of it, I'd say u got it backwards. But, then again I am not sure exactly what u are after and how u plan to implement this feature.
Last edited by jacko (2008-01-06 15:59:10)
Offline
jacko, I modified my wiki entry..... it was late, I was tired, I didn't post everything I intended Thanks.
Offline
jacko, I modified my wiki entry..... it was late, I was tired, I didn't post everything I intended Thanks.
NP, was just wondering myself that's all. Glad someone appreciates my advice.
edit: would just like you to know I edited your wiki page some. Just getting comfortable with the wiki in hopes that I may be able to help out further down the road. I hope the changes I made where OK. I made no real content changes. I would add myself as a tester, but my system is so simplistic in setup that I am not sure that I would be of any use to a project aimed at a prodution level snapshot. I will join archlinux-stable irc channel later to maybe discuss if I can be of some assistance in the future.
Last edited by jacko (2008-01-07 06:03:05)
Offline
Hey everybody,
after we now got some people interested in the topic it is time to move on. I guess it is important that we don't stop, now that it seems some archers are willing to contribute. I think it is time to get something started. I wrote an email to iphitus who offered some help providing a server/storage for the project. I haven't heard back from him yet but hope we will be in contact soon.
As most people in this thread are against the idea of just basic snapshots and want a maintained secure stable branch I think it is a good idea to first start out with the packages in core. What I would suggest doing is, that we chose wich packages to put in there and then try to maintain them for some time. It might make sense to have a pertty much unmaintained snapshot of the extra packages too, that is not part of the stable project, but just for convenience. After some time the packages in the normal extra repo wont be working with our stable core packages cause they depend on libs/kernel etc. from the rolling release.
To figure out which packages to have in core, we could either still just take a snapshot and then make it stable or we could decide what we want in there (concerning versions - I guess the packages themselfs should be the same than in the rolling current to keep things consistent) and then build that new Repo from the ground up.
Just post what you think about this or whether you have totally different ideas. I just try to find an entry point to the whole thing and get us started here. Once we have something that we at least call stable we will have something "real" to talk about. Also don't forget about #archlinux-stable!!!
Thanks and have fun,
nagoola
Offline
For everyone interested here's a short status report on the project:
1. Where are we?
We have stable-repository-server setup for developers use. This server can not be made public due to bandwidth limitation. (If you want help message me(Nihathrael) or rxKaffee for information)
2. What do we need?
- People that are willing to maintain packages, the core repository persists of 166 packages, that will all need maintainers.
- A server/hosting for public use.
- Some help from people experienced with repository maintenance to help us with a few questions.
Open questions for some experienced people:
How do you usually maintain the abs files? (svn,cvs?)
How do you add new files to the repository without breaking it for a short period of time. (Separate server for updates, that is rsynced with the public server after the update has been applied?)
It would be great if someone could write a small tutorial on how to apply security fixes to packages. (I have no experience with this, probably it's handled with patch files, but i guess there will be some coding from hand from time to time).
That's about it for the moment, if you would like to participate please message me(Nihathrael) or rxKaffee or join #archlinux-stable on irc.freenode.net. No knowledge is required, everything can be learned (I am very new to the topic, too).
Also feel free to read/edit the wiki page.
Greetings,
Nihathrael
Unknown Horizons - Open source real-time strategy game with the comfy Anno 1602 feeling!
Offline
I would be interested in offering help with some packages for the x86_64 branch if u have one. Only one huge problem, I am total noob and would need some expert guidance. If that's possible and someone is willing to take me under their wing for some guidance then by all means e-mail me.
I will leave that open for you to decide, since I am not sure what my skills would provide, if any, help. I do learn fast and computers are more then just a hobby for me. Like anything u gotta learn to walk before u can run...
Offline
id gladly help with maintaing packages.
I have not to mutch experience with it but i am willing to learn and i have basic understanding of most linux.
I think this would be a really good thing that you could run an good system like arch insteed of debian on production servers etc.
Offline
Added your name to the wiki, ok?
Offline
Okay, im in the channel but atm im at work so i might be unresponsive.
Offline
While it all sounds like a good idea I am wondering of the real benefits of this project. Will really a core-stable repository with updates every 3 or 6 months be more stable that the current core repo ? I run Arch in a couple of game servers for more than a year now and it seems to be pretty stable as is.
Sorry if I sound negative but this whole idea does not warranty that it will be more stable. Downloading less MBs of updates surely but stability is not just keeping package X only with security updates for Y times. It's more about quality testing the software in a number of situations.
Of course it is a great way to use Arch without that bleeding edge software but then again this leaves the majority of packages (which is in extra) outside.
After posting my concerns, well done for trying to start all of this.
Your source for video guides!
My Linux reviews.
Currently using: Intel Core 2 Quad Q9300 @ 3.5GHz, 2GB RAM, Asus P5E, nVidia Geforce 8800GTS, Arch Linux
Offline
The idea that rare major upgrades are essentially stabler than little minor upgrades seems to be false. You just concentrate the sources of troubles in one rare upgrade.
Also, by reading these forums, I have the impression that the (few) users which experience breakage are just those which do not upgrade often enough, and when they finally update they are not able to deal with the actions suggested by pacman output.
Finally, I wonder how stable snapshots will be chosen: it seems to me that any Arch's snapshot is as stable (and as unstable) as any other.
Anyway, good work.
Mortuus in anima, curam gero cutis
Offline
It's more about quality testing the software in a number of situations.
Should I add you to the wiki?
Offline
Yeah, good luck with this project, but I find Arch to be more than stable as it is.
Offline
We have set up a mailing list for better discussion possibilities:
To subscribe please send a mail with subject "subscribe" to archlinux-stable-request@freelists.org or go here: http://www.freelists.org/list/archlinux-stable
You can also read the archives there, please do so as there will be major posts concerning the project planning in the next hours.
EDIT: Updated the e-mail address. archlinux-stable@freelists.org is only needed to post to the list, NOT to subscribe. Sorry for that mistake!
Last edited by Nihathrael (2008-01-16 16:24:04)
Unknown Horizons - Open source real-time strategy game with the comfy Anno 1602 feeling!
Offline
I'm not sure if this has been said before:
If i get it right, with this project you want to improve the stability and security of the system and you want to avoid that package updates break the system.
So i propose:
Why don't you contribute to the regular arch development and further improve the quality of the packages (which is great in my opinion - i have no problem with the rolling release - this is just what i want) by doing package testing for example? Why create a "branch" instead of joining manpower with the regular arch developers so that all arch users can gain from your work, not only the ones using your snapshots?
Just my two cents. Anyway, respect for the work you do.
Offline
We do not need snapshots.
We do not need to become another awful Ubuntu.
At any given point in time, Arch is rock stable.
The greatest power of Arch is the fact that it continuously flows and evolves.
Last edited by wantilles (2008-01-23 22:26:42)
Offline
The main reason I see for this is the 'full install from a cd' option that from what I understand is gone now. It is intensely annoying to use the 0.8 image and then do an upgrade, therefor it would be useful with a newer snapshot that included core and extra.
Main reason for me is that I need links to get past the Universitys login-page and be able to access any online repo and since links is not in core the installation becomes slightly more complicated.
Offline