Old version repo? (roll-back, testing rep...)

normnmiles · 2004-09-17 13:26:35

This is taken from rasat's post in the "Urgent Request" thread http://bbs.archlinux.org/viewtopic.php? … highlight=

rasat wrote:

I suggest to have an "old-pkg" repo for users to downgrade important packages whenever there is a problem.

+1 I believe this would be a useful repo. I am having a bugger of a problem and having older packages available would be useful. Though how far back would you want to maintain? Just the previous version or all?

I can also see where some would be incline to point users to the cvs and build older packages from there but some packages xorg, gnome or kde are too large and complicated for average users to rebuild.

sarah31 · 2004-09-17 13:53:33

if you find a maintainer for this then sure but i voted no because the maintainers arch ha scan barely take care of what exists as is.

the answer is to stop moving so quickly to the newest releases of large packages. xorg sat in testing for three days and there was no feedback and no apparent problems so they moved it. three days is REALLY NOT ample testing time.

there really needs to be better testing policies for arch. regardless of what the developers think it is time to make some serious attempts at rules and guidelines that enforce quality and not just a rush to satisfy those that want the latest and greatest.

better quality controll will avoid most of the issues arch packages have. that is why i continually say arch needs more devs that can spend alot of time on arch and not on other necessary things like school and work. (don't take that as a knock developers it is just a comment. you need your other jobs and school of course.)

Mr Green · 2004-09-17 14:53:41

patience is the key...

less haste more speed

O yeah I voted no.....

normnmiles · 2004-09-17 15:43:28

hummm...so far nobody likes this idea except me. Oh well.

Question: Where do you all get older packages when you need them? Or is it that nobody ever deletes their pacman cache or does a fresh install?

Mr Green · 2004-09-17 15:49:03

like you say pacman cache .... O & like back up....

sarah31 · 2004-09-17 15:54:35

since i can always boot into console i will just rebuild using an older PKGBUILD obtained from the web CVS interface. That or just modify the PKGBUILD myself to build an older version. Often my ABS is not as current as the most recent package tree so i often have very few issues if older packages needed patches.

i also have learned to wait for more feedback when major packages are released. personally i don't like doing that but since there have been no moves to standardize the whole packaging system with arch, including tesing and releasing, it is the best policy. i hate having no functioning box more than having the newest kernel or Xorg or whatever.

having a "old" repo would only let the maintainers off the hook for instituting better quality control. that is why i voted no. having a stable/old repo is great only if you have the proper quality control in place.

sweiss · 2004-09-17 16:03:04

I also think fixed and strict packaging rules regarding the moving of packages across the repositories will solve a lot of issues and will cause much less trouble.

I think there are enough people who use testing, they just need the time. If you have issues with the packages in testing, you can always downgrade using current. Also, this way the developers and package maintainers will not be so stressed out to fix the problem in such a hurry, which will probably generate better solutions to the various problems.

normnmiles · 2004-09-17 16:16:11

sweiss wrote:

If you have issues with the packages in testing, you can always downgrade using current.

I agree with the reasonings why having an old repo would be detrimental to developers. But what happens if the problem you are experiencing is with the packages in current and you don't have access to the previous version?

For example, I have having a lot of difficulties with my desktop environment (xorg and xfce4). The windows will not draw correctly. This is with a fresh FTP install of Arch. Xfce4 hasn't really changed since July so I think the problem is with xorg but I don't have access to the previous version of xorg to see if it is causing the problem or something else.

i3839 · 2004-09-17 16:47:13

A seperate repo with old packages doesn't make sense, but a seperate dir on the Arch ftp server with all old the packages may be useful. It won't be used often, so it hardly causes extra bandwidth usage, it just takes diskspace. When it becomes too big the oldest packages can be deleted. Shouldn't be much work maintaining that, just a matter of moving the old files to it instead of deleting them. And running the prune script can be done by cron.

sweiss · 2004-09-18 08:22:05

normnmiles wrote:

sweiss wrote:
If you have issues with the packages in testing, you can always downgrade using current.
For example, I have having a lot of difficulties with my desktop environment (xorg and xfce4). The windows will not draw correctly. This is with a fresh FTP install of Arch. Xfce4 hasn't really changed since July so I think the problem is with xorg but I don't have access to the previous version of xorg to see if it is causing the problem or something else.

Well, what's done is done, I'm afraid. This is why we suggest this new scheme. As for the current situation, perhaps the new xorg should be moved back to testing.

I still have the old xorg package in my cache, in case you need to re-upload it to the repos.

P.S.
What are those rendering issues you're having? I'm using xfce4 and xorg without much trouble.

rasat · 2004-09-18 09:18:33

sarah31 wrote:

having a "old" repo would only let the maintainers off the hook for instituting better quality control. that is why i voted no.

One year ago when AL had around 400 registered users I would had to some extent agreed with sarah31. But not now with 2000 users waiting for their machines to crash for the sake of getting the maintainers / developers to discover bugs and start thinking about solutions. Its not fair.

Earlier we (AL) had a problem with documentation and we found a solution by putting both users' and devs' heads together. This package issue we can also solve in a similar manner though we didn't do that well with the "incoming package" issue But at least we should try.

At this moment I am more concern about the users to have a stable machine or at least be able to quickly handle defective packages whenever occure, instead of only concentrating on the maintainers' problem. Moreover I don't think the maintainers can 100% solve the issue when often bugs are in the source itself.

To keep an old package repo is a solution but there is the question how/who will maintain though I would suggest only to keep the latest stable version.

What could also be done is to have a "roll-back" option in pacman. Pacman will ask the user if wanting to keep a backup of the old package by storing the old files into an AL pkg tarball before installing the new package.

murkus · 2004-09-18 09:35:04

rasat wrote:

What could also be done is to have a "roll-back" option in pacman. Pacman will ask the user if wanting to keep a backup of the old package by storing the old files into an AL pkg tarball before installing the new package.

Though I voted yes I think I'd change my vote to no if rasat's roll-back suggestion would be implemented in pacman instead.

.murkus

Mr Green · 2004-09-18 10:34:17

I think we have had this subject before .... not that a roll-back option is a bad idea ...

The release of packages is getting sooner which is causing the problem testing is important ... so what happens

Aunt Tillie wants the latest version of knitting pattern creator.... Kpattern

she is so eager to try the new package she demands that it is updated A.s.a.p.

Then disaster strikes Kpackage throws out errors upsets system & even worse crashes .....

... back to the forum starts asking what wrong with it ... why was it not tested etc.. so forth.

The moral of this strory is ...

If you want the latest & greatest version build it yourself....PKBUILD's are your friend

Do not go moaning to the devs. when it all goes wrong

They need support .......

Positive feedback is the way forward & Arch will become stronger....

sarah31 · 2004-09-18 12:07:06

rasat wrote:

sarah31 wrote:
having a "old" repo would only let the maintainers off the hook for instituting better quality control. that is why i voted no.
One year ago when AL had around 400 registered users I would had to some extent agreed with sarah31. But not now with 2000 users waiting for their machines to crash for the sake of getting the maintainers / developers to discover bugs and start thinking about solutions. Its not fair.
Earlier we (AL) had a problem with documentation and we found a solution by putting both users' and devs' heads together. This package issue we can also solve in a similar manner though we didn't do that well with the "incoming package" issue But at least we should try.
At this moment I am more concern about the users to have a stable machine or at least be able to quickly handle defective packages whenever occure, instead of only concentrating on the maintainers' problem. Moreover I don't think the maintainers can 100% solve the issue when often bugs are in the source itself.
To keep an old package repo is a solution but there is the question how/who will maintain though I would suggest only to keep the latest stable version.
What could also be done is to have a "roll-back" option in pacman. Pacman will ask the user if wanting to keep a backup of the old package by storing the old files into an AL pkg tarball before installing the new package.

so basically you want the developers to not use testing and roll out packages that are bug riddled and hope for the best?

With 2000 plus users you say (are you sure it is not more or less because there are X users registered here does not mean that they are all active or use arch) you would prefer them to have broken machines and report bugs than have hopefully machines after a package has sat in testing for some time.

I just don't get it. All I am suggesting is a concerted effort to get some standards and practises incorporated that will give users the confidence that pacman -Syu will not break their system if they only use current and extra.

Whatever... I would rather see an effort to be renowned as a stable distro than an "almost-but-not-quite-there" distro. for me arch has been stable but it has required effort at many points in time. I know not to install big packages right away, no matter how much I may want or need them. imo that simply should not be. when i used debian (and i am talking unstable here) i had no worries about installing the "latest" packages because they rarely had bugs even then (the problem was always gnome or galeon issues which is not a surprise and which caused me to stop using these apps/desktop environments). with arch i rarely upgrade right away when i see that packages such as xorg, kernel26, glibc or gcc are upgraded.

blindly upgrading just isn't an option anymore.

sweiss · 2004-09-18 12:12:11

rasat wrote:

What could also be done is to have a "roll-back" option in pacman. Pacman will ask the user if wanting to keep a backup of the old package by storing the old files into an AL pkg tarball before installing the new package.

Is it that simple to implement?

Would be one hell of a feature in any case.

normnmiles · 2004-09-18 13:39:16

I feel that most people really dislike the idea an additional "repo" but like i3839 suggests a seperate directory would also work. Is this a better idea since technicially it's not another repo to maintain?

Mr Green · 2004-09-18 13:41:30

sweiss wrote:

rasat wrote:
What could also be done is to have a "roll-back" option in pacman. Pacman will ask the user if wanting to keep a backup of the old package by storing the old files into an AL pkg tarball before installing the new package.
Is it that simple to implement?
Would be one hell of a feature in any case.

No , leave pacman alone .....

rasat · 2004-09-19 05:17:12

sarah31 wrote:

so basically you want the developers to not use testing and roll out packages that are bug riddled and hope for the best?

No, I want to reduce the pressure devs get when a package fail and can take their own time to fix the problem. A user will not much complain (peacefully alert the devs) if he/she will be able to downgrade with a simple key stroke. Main concern for an user not to get stranded e.g. not able to print for few days when CUPS fails (this happened 7-8 months ago).

sweiss wrote:

Is it that simple to implement?

Pacman can identify the content of a package, the script would be quite simple. The simplest script would be just to save the downloaded pkg we want to roll back, in another folder than /var/cache/pacman/pkg. Here someone may ask why not the user do it manually. New users are not aware of it and the old users may forget to do it. To automate this roll-back idea, the pacman.conf could have a default configure of packages same like the "NoUpgrade".

Mr Green wrote:

If you want the latest & greatest version build it yourself....PKBUILD's are your friend.
Do not go moaning to the devs. when it all goes wrong.

Here we are not speaking about "beta" packages but in current and extra what users consider as stable. They have right to moan when the previous version is no longer available or was not tested properly before adding in extra.

kakabaratruskia · 2004-09-19 06:37:04

I think this is kind of transforming arch into debian.... some kind of stable/unstable. It could be very possitive, but I don't know if there are enough resources (people mostly) to do it.

About the pacman roll-back idea... I don't like it much... can't give arguments, it just doesn't sound clean to me.

Mr Green · 2004-09-19 08:35:34

So far over I have only ever had to roll-back (sounds like Asda!) once ...

Its rare to have to do it so why bother changing pacman just to do it maybe once or twice a year !

patience is the key ....

IceRAM · 2004-09-19 09:00:51

Mr Green wrote:

patience is the key ....

+1 from me.

sweiss · 2004-09-19 12:25:50

rasat wrote:

sweiss wrote:
Is it that simple to implement?
Pacman can identify the content of a package, the script would be quite simple. The simplest script would be just to save the downloaded pkg we want to roll back, in another folder than /var/cache/pacman/pkg. Here someone may ask why not the user do it manually. New users are not aware of it and the old users may forget to do it. To automate this roll-back idea, the pacman.conf could have a default configure of packages same like the "NoUpgrade".

What happens when a package has install scripts? Can those be also rolled back?

IceRAM · 2004-09-19 12:38:03

Simple idea: Bleeding-edge, but X days old.

Experienced users (and the ones which keep the cache) which know (can) rollback will set the time restriction to 0.

paranoos · 2004-09-19 16:36:10

Why not just use what we already have: the Testing repo.

I believe we should promote people to use Testing as their first repo, and to "roll back" to Current if it does not work (once they filed a bug report at least). For example, if a user does -Syu and the new testing/xorg is giving them problems, they can "pacman -S current/xorg".

We should also set a standard: perhaps all new upstream versions should go to Testing. How long should a package be in Testing before it's sent to Current / Extra? If enough users are actually running Testing, and we get real feedback, then a perhaps week would be sufficient.

rasat · 2004-09-19 16:41:32

sweiss wrote:

What happens when a package has install scripts? Can those be also rolled back?

I don't know how pacman handles the install script. I have summarized this topic and sent a pm to apeiro.

Arch Linux

#1 2004-09-17 13:26:35

Old version repo? (roll-back, testing rep...)

#2 2004-09-17 13:53:33

Re: Old version repo? (roll-back, testing rep...)

#3 2004-09-17 14:53:41

Re: Old version repo? (roll-back, testing rep...)

#4 2004-09-17 15:43:28

Re: Old version repo? (roll-back, testing rep...)

#5 2004-09-17 15:49:03

Re: Old version repo? (roll-back, testing rep...)

#6 2004-09-17 15:54:35

Re: Old version repo? (roll-back, testing rep...)

#7 2004-09-17 16:03:04

Re: Old version repo? (roll-back, testing rep...)

#8 2004-09-17 16:16:11

Re: Old version repo? (roll-back, testing rep...)

#9 2004-09-17 16:47:13

Re: Old version repo? (roll-back, testing rep...)

#10 2004-09-18 08:22:05

Re: Old version repo? (roll-back, testing rep...)

#11 2004-09-18 09:18:33

Re: Old version repo? (roll-back, testing rep...)

#12 2004-09-18 09:35:04

Re: Old version repo? (roll-back, testing rep...)

#13 2004-09-18 10:34:17

Re: Old version repo? (roll-back, testing rep...)

#14 2004-09-18 12:07:06

Re: Old version repo? (roll-back, testing rep...)

#15 2004-09-18 12:12:11

Re: Old version repo? (roll-back, testing rep...)

#16 2004-09-18 13:39:16

Re: Old version repo? (roll-back, testing rep...)

#17 2004-09-18 13:41:30

Re: Old version repo? (roll-back, testing rep...)

#18 2004-09-19 05:17:12

Re: Old version repo? (roll-back, testing rep...)

#19 2004-09-19 06:37:04

Re: Old version repo? (roll-back, testing rep...)

#20 2004-09-19 08:35:34

Re: Old version repo? (roll-back, testing rep...)

#21 2004-09-19 09:00:51

Re: Old version repo? (roll-back, testing rep...)

#22 2004-09-19 12:25:50

Re: Old version repo? (roll-back, testing rep...)

#23 2004-09-19 12:38:03

Re: Old version repo? (roll-back, testing rep...)

#24 2004-09-19 16:36:10

Re: Old version repo? (roll-back, testing rep...)

#25 2004-09-19 16:41:32

Re: Old version repo? (roll-back, testing rep...)

Board footer