Suggestion: Snapshot of extra repository

potentials · 2004-05-19 21:30:02

From what I understand some people tend to feel that Arch is buggy or unstable because they upgrade or install some new packages without upgrading the whole system so they end up with inconsistent system (old and new packages aren't consistent with each other). The other case is that people upgrade while the packages in the repository itself aren't consistent with each other due to the fact that the repository is in a transition phase (some package is upgraded which requires alot of other packages to be rebuilt).

Both cases can be avoided if we have a snapshot of the repositories along with the the already existing dynamic repositories, these snapshot repositories should guaranteed be as closer to being buggy free as possible. People who are stabitliy/security paraniods can always safely use these snapshots, same as with dialup users who want to install new packages without upgrading the whole system. The release repository already does that but the problem is that it's only a snapshot of the "current" repository. If we have another snapshot of "extra" if would be great. We'll end up having "release-current" and "release-extra" along with "current" and "extra".

Already most if not all the binary based distros I can think of have static repositories and no continuously updated repositories, ofcourse if Arch does as those distros do it will lose one of its main advantages of having the latest packages available.

The "release-extra" repository may or maynot be released as extra ISOs with each Arch release.

As with the repository undergoing a transtition there could be a field in the database file in the repository that pacman checks and warns the users if the repo is currently under a repairing/rebuilding phase, ofcourse the user sould have the option to continue upgrading anyway.

dp · 2004-05-19 21:53:32

if people update only one pkg, and do not keep their systems up to date (-Suy), then it's their own problem having an inconsistent system

the other thing is update of important pkgs that carry with them rebuild of a lot of pkgs --- this is solved by using testing-repo for such updates

making ISO's of extra is not that easy, because it's 1.4GB big - without kde+gnome about 990MB - a DVD is possible, but not a lot of people have dvd-burners

i3839 · 2004-05-19 22:58:18

I think the best sollution is, as already stated by someone somewhere else, to have an extra option in Pacman which tells how old the packages must be before installing them (mainly for system upgrades). That way you can for instance demand that packages are at least one week old, and thus already tested by other users, before installing them. Then you have a sort of "snapshot" of the packages too.

potentials · 2004-05-19 23:01:19

if people update only one pkg, and do not keep their systems up to date (-Suy), then it's their own problem having an inconsistent system

Dialup users always do that, not that its that they expect their system not to break if they do, but they can't help it.

making ISO's of extra is not that easy, because it's 1.4GB big

If so then atleast provide the "release-extra" online repository, it'll do the job.

potentials · 2004-05-19 23:11:42

Maybe I didn't make myself clear, the "snapshot" must be taken at the time a new release is done. As far as I know the released ISO contains a snapshot of the "current" repository at some moment. The snapshot of "extra" would be totatlly consistent with that of "current". So if a user installs using the base iso or the full iso and then adds new packages from "release-current" and "release-extra" he'll be to some extent safe.

kpiche · 2004-05-20 00:30:13

Isn't that what the "release" repository is for? It only gets updated when there's a new release. Check /etc/pacman.conf.

potentials · 2004-05-20 00:36:29

potentials wrote:

The release repository already does that but the problem is that it's only a snapshot of the "current" repository.

Dusty · 2004-05-20 00:44:15

dp and I are on dialup and we Syu instead of one package at a time. I do it every day, usually nothing needs to be updated. A snapshot of extra to go with the releases would be utterly useless to anybody who keeps up to date, which is what Arch is designed for.

People that want to stick with release is where the problem lies. An extra snapshot would indeed solve the problem, only without a CD of the extra snapshot, you'd have to download anyway.

Even so, you would know it was a stable release and wouldn't have to keep programs up to date. I think it's a good idea. I just don't know how many people would use it; would it justify the space it would take up?

Dusty

dp · 2004-05-20 00:47:25

potentials wrote:

potentials wrote:
The release repository already does that but the problem is that it's only a snapshot of the "current" repository.

after a release, you suggest that there is a other repository made from extra, that stays at the stage when the new release came out and is not updated in the meanwhile

what i was a little bit confused with the idea was that you spoke about snapshots, that are often of very short lifetime in opensource-projects --- yes such extra-release repo can be helpfull

potentials · 2004-05-20 13:00:17

Dusty wrote:

dp and I are on dialup and we Syu instead of one package at a time. I do it every day, usually nothing needs to be updated.

I'm on dialup too, but if I Syu then I'll have to download 100MB+ to update KDE. I had to download KDE on broadband then get it home on a CD to install it in the first place, now if I want to install say kile ( which I didn't download and install before) then I'll have to upgrade to KDE 3.2.2 because I have KDE 3.2.0. That's tens and tens of megas to download. That's just an example. Anyway, some agree its a good idea but the remaining question is whether its worth it.

How many dialup users would really like the idea?
How many broadband users prefer stability and won't install packages except from the proposed repository?

What do u guys think?

Mr Green · 2004-05-20 13:25:48

I think an easy way round dial problems may be what you already do....

I know how bad dial up is so anything to ease the pain would be a big help

Its not the perfect soulution but maybe a step in the right direction

Arch bringing Linux Users together....United we stand divided we Fall...

I'm sure your local friendly Arch user would only be glad to help out..

Mr Green

Dusty · 2004-05-20 22:08:20

potentials wrote:

I'm on dialup too, but if I Syu then I'll have to download 100MB+ to update KDE.

I downloaded KDE over a period of about 6 nights. :-D And I only use it because I can't get any dialer besides kppp to work! :-D

What do u guys think?

The developers basically say that Arch is made to run from the current repository and if you don't Syu, you're on your own. The main problem with supporting "old" software is that we don't have enough man-hours to backport security fixes and such to the stable repository. There aren't any garuntees, but current is actually more likely to be stable and secure than a snapshot. The snapshots aren't taken at a point of stability, it's just what current was like at one time. There is no reason that current shouldn't be used instead.

The dialup issue is a major one. Arch wasn't made and isn't maintained for dialup connections. There was discussion once of using binary diffs to ease the load. I doubt that will ever happen with Arch, but it's possible there will be such a distro available someday. (Seems every *other* sort of distro is available!!!)

Dusty

filoktetes · 2004-05-21 02:09:13

My experience is that Arch is very stable most of the time. The problems with unstability and broken dependencies comes at the rare times when major packages have been updated, which also have many other packages depending on them, so that they also have to be recompiled, and so on.

I propose one of these two solutions to minimise the problem. I prefer the first one, which is the simplest:

:idea:1. When the developers suspect that a package update will make the system unstable, let them define a testing state of the system. Then let pacman refuse to update the system as long as the testing state lasts, except if you specify the -testing option.

That way people who need to have a solid system at all times will have that posibillity, and those who wish to have new packages as quickly as possible can have that too, while they also contribute by testing the system.

or

:idea:2. Make a new testing repo, where packages are updated continuously, and set a timespan of e.g one week for packages to automatically be transfered to current, as long as no problems has been reported for the package update.

Both of these waysofdoings would work almost the same way, I think, but I sort of dislike the notion of having a "stable" and "unstable" repo. That's too Debian for me . And this is still no improvement for those poor people with slow connections who want to install new packages into an old system.

Of course I know that almost everything that can be said about these things already has been said, but I just thought that I should be allowed to say it too

Xentac · 2004-05-21 03:18:00

reb wrote:

I propose one of these two solutions to minimise the problem. I prefer the first one, which is the simplest:
:idea:1. When the developers suspect that a package update will make the system unstable, let them define a testing state of the system. Then let pacman refuse to update the system as long as the testing state lasts, except if you specify the -testing option.
That way people who need to have a solid system at all times will have that posibillity, and those who wish to have new packages as quickly as possible can have that too, while they also contribute by testing the system.
or
:idea:2. Make a new testing repo, where packages are updated continuously, and set a timespan of e.g one week for packages to automatically be transfered to current, as long as no problems has been reported for the package update.

We already do part of both of these. This amazing -testing option you speak of is called the testing repo. We use it for large, problematic updates. The testing repo is the same one as you mention in idea 2

The problem with idea 2 is that we want to have current as up to date as possible. The majority of updates don't screw up the system, as you said, so why delay them if it just means that a package will take that much longer to be released?

beniro · 2004-05-21 19:57:42

We covered this a couple of weeks ago. Actually I mentioned exacltly above's idea #2, with a flag to set within pacman.conf whether you'd like to forgo the 1 week waiting period.

Anyway, the point is this: The DEVs have already decided on a new system, which they will unveil soon. It should fix these problems, and make Arch as stable as it has been in the past: rock solid.

I can't wait!

Arch Linux

#1 2004-05-19 21:30:02

Suggestion: Snapshot of extra repository

#2 2004-05-19 21:53:32

Re: Suggestion: Snapshot of extra repository

#3 2004-05-19 22:58:18

Re: Suggestion: Snapshot of extra repository

#4 2004-05-19 23:01:19

Re: Suggestion: Snapshot of extra repository

#5 2004-05-19 23:11:42

Re: Suggestion: Snapshot of extra repository

#6 2004-05-20 00:30:13

Re: Suggestion: Snapshot of extra repository

#7 2004-05-20 00:36:29

Re: Suggestion: Snapshot of extra repository

#8 2004-05-20 00:44:15

Re: Suggestion: Snapshot of extra repository

#9 2004-05-20 00:47:25

Re: Suggestion: Snapshot of extra repository

#10 2004-05-20 13:00:17

Re: Suggestion: Snapshot of extra repository

#11 2004-05-20 13:25:48

Re: Suggestion: Snapshot of extra repository

#12 2004-05-20 22:08:20

Re: Suggestion: Snapshot of extra repository

#13 2004-05-21 02:09:13

Re: Suggestion: Snapshot of extra repository

#14 2004-05-21 03:18:00

Re: Suggestion: Snapshot of extra repository

#15 2004-05-21 19:57:42

Re: Suggestion: Snapshot of extra repository

Board footer