Bleeding-edge, but X days old

IceRAM · 2004-09-19 09:49:50

In the light of the recent debates on creating an "old" repository, I come and throw in another idea.

I usually update my system (pacman -Syu) every few days, because some of the packages tend to be rebuild with some new tweak and I often find myself installing newversion-2.

Wouldn't it be nice if pacman checked the release package date and get me only the packages older than.. let's say... 5 days (configurable). An option in /etc/pacman.conf would do. If someone wants to have a really bleeding-edge system, he/she can set this to 0.
If a package suffers updates every 3 days and I have this time restriction set for 5 days, I'll download it only when 5 days passed from the last update.

This option should work only for -u. If someone calls "pacman -S packagename", a warning could be shown saying that the time restriction is ignored and the latest package is downloaded.

A command line option to ignore the time restriction would also be good, to work in conjunction with -u, something like -Syun (n from now).

What do you think?

Of course, the package db should provide the needed information (package build date/time).

Pajaro · 2004-09-19 13:04:07

very good idea

But It has just one point, and it comes when you are installing arch for the first time: you cannot get a five days old package, you have to get the one avaible. so the old_repo would be also great... an old repo with only package versions that are know to work (only think i miss from debian, a stable repo). I know that arch is bleeding edge, but arch appart from bleeding edge is easy, so i think that would be good to have an "almost bleding edge, known to be stable" repo.

i3839 · 2004-09-19 13:19:16

Funny. :-)

I wrote the necessary patches for gensync and Pacman already, sent them to Judd three weeks ago (24 August). I implemented it as an option to pacman.conf named "UpgradeDelay". I had no feedback yet, and it doesn't seem to be in the newest pacman, so no idea what it's current status is.

For the curious here the patches:

--- pacman-2.8.3/scripts/gensync    2004-08-04 04:28:48.000000000 +0200
+++ pacman-2.8.3-iz/scripts/gensync    2004-08-18 15:41:05.000000000 +0200
@@ -126,6 +126,8 @@
         done
         echo "" >>depends
     fi
+    # preserve the modification time
+    touch -r $1 desc depends
 }
 
 if [ $# -lt 2 ]; then

diff -Nurp -x '*.[o]' pacman-2.8.3.orig/src/db.c pacman-2.8.3-ud/src/db.c
--- pacman-2.8.3.orig/src/db.c    2004-08-04 04:24:52.000000000 +0200
+++ pacman-2.8.3-ud/src/db.c    2004-08-24 01:46:04.000000000 +0200
@@ -155,7 +155,8 @@ pkginfo_t* db_scan(pacdb_t *db, char *ta
 pkginfo_t* db_read(pacdb_t *db, struct dirent *ent, unsigned int inforeq)
 {
     FILE *fp = NULL;
-    struct stat buf;
+    int fd;
+    struct stat st;
     pkginfo_t *info = NULL;
     char path[PATH_MAX];
     char line[512];
@@ -167,23 +168,19 @@ pkginfo_t* db_read(pacdb_t *db, struct d
     /* we always load DESC */
     inforeq |= INFRQ_DESC;
 
-    snprintf(path, PATH_MAX, "%s/%s", db->path, ent->d_name);
-    if(stat(path, &buf)) {
-        /* directory doesn't exist or can't be opened */
-        return(NULL);
-    }
-
     info = newpkg();
 
     /* DESC */
     if(inforeq & INFRQ_DESC) {
         snprintf(path, PATH_MAX, "%s/%s/desc", db->path, ent->d_name);
         fp = fopen(path, "r");
-        if(fp == NULL) {
+        fd = fileno(fp);
+        if(fp == NULL || fstat(fd, &st)) {
             fprintf(stderr, "error: %s: %sn", path, strerror(errno));
             FREEPKG(info);
             return(NULL);
         }
+        info->date = st.st_mtime;
         while(!feof(fp)) {
             if(fgets(line, 256, fp) == NULL) {
                 break;
@@ -349,7 +346,7 @@ pkginfo_t* db_read(pacdb_t *db, struct d
     /* INSTALL */
     if(inforeq & INFRQ_ALL) {
         snprintf(path, PATH_MAX, "%s/%s/install", db->path, ent->d_name);
-        if(!stat(path, &buf)) {
+        if(!stat(path, &st)) {
             info->scriptlet = 1;
         }
     }
diff -Nurp -x '*.[o]' pacman-2.8.3.orig/src/package.h pacman-2.8.3-ud/src/package.h
--- pacman-2.8.3.orig/src/package.h    2004-07-03 06:25:47.000000000 +0200
+++ pacman-2.8.3-ud/src/package.h    2004-08-23 22:59:00.000000000 +0200
@@ -55,6 +55,7 @@ typedef struct __pkginfo_t {
     unsigned long size;
     unsigned short scriptlet;
     unsigned short force;
+    time_t date;
     PMList *replaces;
     PMList *groups;
     PMList *files;
diff -Nurp -x '*.[o]' pacman-2.8.3.orig/src/pacman.c pacman-2.8.3-ud/src/pacman.c
--- pacman-2.8.3.orig/src/pacman.c    2004-08-04 07:57:17.000000000 +0200
+++ pacman-2.8.3-ud/src/pacman.c    2004-08-24 00:49:10.000000000 +0200
@@ -93,6 +93,7 @@ PMList        *pmo_ignorepkg    = NULL;
 PMList        *pmo_holdpkg      = NULL;
 unsigned short pmo_usesyslog    = 0;
 unsigned short pmo_nopassiveftp = 0;
+time_t         pmo_upgradedelay = 0;
 
 
 /* list of sync_t structs for sync locations */
@@ -595,8 +596,7 @@ int pacman_sync(pacdb_t *db, PMList *tar
         }
         FREELIST(reps);
     } else if(pmo_s_upgrade) {
-        int newer = 0;
-        int ignore = 0;
+        int notall = 0;
         syncpkg_t *s = NULL;
 
         logaction(NULL, "starting full system upgrade");
@@ -613,7 +613,7 @@ int pacman_sync(pacdb_t *db, PMList *tar
                             if(is_in(p->name, pmo_ignorepkg)) {
                                 fprintf(stderr, ":: %s-%s: ignoring package upgrade (to be replaced by %s-%s)n",
                                     p->name, p->version, pkg->name, pkg->version);
-                                ignore = 1;
+                                notall = 1;
                             } else if(yesno(":: Replace %s with %s from "%s"? [Y/n] ", p->name, pkg->name, dbs->db->treename)) {
                                 /* if confirmed, add this to the 'final' list, designating 'p' as
                                  * the package to replace.
@@ -679,7 +679,7 @@ int pacman_sync(pacdb_t *db, PMList *tar
                 /* local version is newer */
                 fprintf(stderr, ":: %s-%s: local version is newern",
                     local->name, local->version);
-                newer = 1;
+                notall = 1;
                 FREE(sync);
                 continue;
             } else if(cmp == 0) {
@@ -690,7 +690,14 @@ int pacman_sync(pacdb_t *db, PMList *tar
               /* package should be ignored (IgnorePkg) */
                 fprintf(stderr, ":: %s-%s: ignoring package upgrade (%s)n",
                     local->name, local->version, sync->pkg->version);
-                ignore = 1;
+                notall = 1;
+                FREE(sync);
+                continue;
+            } else if(istoonew(sync->pkg)) {
+              /* package too new (UpgradeDelay) */
+                fprintf(stderr, ":: %s-%s: delaying upgrade of package (%s)n",
+                    local->name, local->version, sync->pkg->version);
+                notall = 1;
                 FREE(sync);
                 continue;
             }
@@ -709,7 +716,7 @@ int pacman_sync(pacdb_t *db, PMList *tar
                 }
             }
         }
-        if((newer || ignore) && allgood) {
+        if(notall && allgood) {
             fprintf(stderr, ":: Above packages will be skipped.  To manually upgrade use 'pacman -S <pkg>'n");
         }
         /* check if pacman itself is one of the packages to upgrade.  if so, we
@@ -3474,6 +3481,17 @@ int parseconfig(char *configfile)
                         FREE(pmo_xfercommand);
                         pmo_xfercommand = strndup(ptr, PATH_MAX);
                         vprint("config: xfercommand: %sn", pmo_xfercommand);
+                    } else if (!strcmp(key, "UPGRADEDELAY")) {
+                        /* The config value is in days, we use seconds */
+                        pmo_upgradedelay = (60*60*24) * atol(ptr);
+                        vprint("config: UpgradeDelay: %in", pmo_upgradedelay);
+                        /* Warn when the delay is rather high (two months for now) */
+                        if (pmo_upgradedelay > (60*60*24) * 60){
+                            fprintf(stderr, "Warning: UpgradeDelay is very high.n"
+                                "If a package is updated often it will never be upgraded.n"
+                                "Manually update such packages or use a lower value "
+                                "to avoid this problem.n");
+                        }
                     } else if (!strcmp(key, "PROXYSERVER")) {
                         char *p;
                         if(pmo_proxyhost) {
@@ -3760,6 +3778,16 @@ int lckrm(char *file)
     return(unlink(file));
 }
 
+int istoonew(pkginfo_t* pkg){
+    time_t t;
+    if (!pmo_upgradedelay){
+        return 0;
+    }
+    time(&t);
+    printf("istoonew: time=%lu, date=%lun", t, pkg->date);
+    return((pkg->date + pmo_upgradedelay) > t);
+}
+
 void cleanup(int signum)
 {
     PMList *lp;
diff -Nurp -x '*.[o]' pacman-2.8.3.orig/src/pacman.h pacman-2.8.3-ud/src/pacman.h
--- pacman-2.8.3.orig/src/pacman.h    2004-08-04 07:57:17.000000000 +0200
+++ pacman-2.8.3-ud/src/pacman.h    2004-08-24 00:36:22.000000000 +0200
@@ -74,6 +74,7 @@ char* buildstring(PMList *strlist);
 int yesno(char* fmt, ...);
 int lckmk(char *file, int retries, unsigned int sleep_secs);
 int lckrm(char *lckfile);
+int istoonew(pkginfo_t* pkg);
 void cleanup(int signum);
 
 #endif /* PACMAN_H */

The printf in istoonew is only for debugging purposes.

IceRAM · 2004-09-19 13:20:05

Hmm.. running pacman after a clean install?
1. set the default time restriction to 0 && put a warning somewhere for the people wanting to make their system X-days less bleeding edge
2. pacman -Syun (-n = no time restriction)
3. when "pacman -Syu" return nothing offer to get the latest packages, ignoring the Time Restriction

There are so many alternatives...
People just need to discuss them.

IceRAM · 2004-09-19 13:29:04

i3839 wrote:

Funny. :-)
I wrote the necessary patches for gensync and Pacman already, sent them to Judd three weeks ago (24 August). I implemented it as an option to pacman.conf named "UpgradeDelay". I had no feedback yet, and it doesn't seem to be in the newest pacman, so no idea what it's current status is.
For the curious here the patches:
[...]

Hmm... 3 weeks ago?
Anyway... this idea seemed too simple not to be already brought up.
Great to see there's a patch already.
Could you please tell us what it provides, besides the behaviour?
Any extra switches etc.?

Have you submitted a bug report (actually a feature request) to FlySpray (http://bugs.archlinux.org)? Judd checks it from time to time and before pacman releases. Everything put there by me got an answer sooner or later (but I admit, it wasn't 3 weeks later).

i3839 · 2004-09-19 14:29:17

First I sent him the gensync patch, explaining for what it was needed, and he reacted positive. So I made the Pacman patch and sent that too. He didn't post for a while on the mailinglist either, so I assume he is/was on vacation and/or is very busy. I was more or less waiting for the next Pacman release before I'd send him another mail asking for information. I didn't use the bugtracker because posting patches there is painful and because it's a very Pacman specific thing, so didn't seem to fit very well. And he replied to my emails.

The gensync patch preserves the modification time of the files that are going to be part of the package database. That way we can check the mtime of a package file in the DB to get it's date and we don't need a seperate DB entry with the package date, making things simpler and the DB smaller.

The Pacman patch adds just an extra check in the sysupdate option to check that the package's buildtime is older than the UpgradeDelay time. The interface in the current form is only an extra option for pacman.conf, but adding commandline options should be trivial.

A "UpgradeDelay" option in pacman.conf makes most sense I think, because in general you'd want to have a system with a consistent delay time, so you don't want to give that as an commandline option everytime. Adding extra cmd options to ignore the delay etc. may be useful, but not needed for a basic working implementation. Not to mention that I have no idea which character to use. An option that just says "upgradedelay is zero" isn't very useful, because with -Su you get a list of packages that are ignored because of the date, so you can always manually upgrade them. What's more useful is an option to tell what the upgrade delay is, so you can use another delay without editing pacman.conf. 'u', 'd' and 'w' are taken already, only one left that would make some sense is 't' for 'delay time'.

sweiss · 2004-09-19 14:38:03

Frankly I don't think modifying pacman will provide the solution. Packages should just stay in testing a little longer, so that they actually get tested. It's just that "current" and "extra" must be defined as "stable" instead of "almost stable".

Since the maintainers obviously don't have 100 machines and configurations to test a package on, I think a rollback feature, if indeed simple to implement, will provide a sufficient safety net.

The rollback feature is actually needed for things which are not related to the packages themselves. A good example would (unfortunately) be the latest kernel releases, which have caused quite a few problems quite a few people. The rollback feature is a great remedy for situations as such alone.

IceRAM · 2004-09-19 14:39:40

i3839 wrote:

I didn't use the bugtracker because posting patches there is painful and because it's a very Pacman specific thing, so didn't seem to fit very well. And he replied to my emails.

Well, you could create a FlySpray task and link this thread in it. Mails can get lost, forgotten.. etc. FlySpray task are left behind after they're closed.

i3839 wrote:

The Pacman patch adds just an extra check in the sysupdate option to check that the package's buildtime is older than the UpgradeDelay time. The interface in the current form is only an extra option for pacman.conf, but adding commandline options should be trivial.

Do you happen to know if the Date/Time is stored in UTC by makepkg (and checked accordingly by pacman)? I once had some problems with a ./configure script which reported a bad time for my system because the sources were compressed and bad timestamps were created.

i3839 wrote:

What's more useful is an option to tell what the upgrade delay is, so you can use another delay without editing pacman.conf. 'u', 'd' and 'w' are taken already, only one left that would make some sense is 't' for 'delay time'.

Even better...

Showing delayed packages is also better.

i3839 · 2004-09-19 15:42:20

This Pacman modification isn't the solution, but is a good one that catches most of the cases. It's also very easy to implement, requires not much extra code and causes absolutely no extra maintenance.

You can hardly implement a rollback feature without editing Pacman. Sure, you can make a Pacman wrapper, but who are you fooling then? The rollback thing won't help you if some install script screwed it up for you, then the damage is done already. And you can already do rollbacks manually with just installing the old package from the cache.

The date stored by makepkg is in UTC yes, it's stored as a string and Pacman does absolutely nothing with it, except printing it out when you do -Qi. Hell doesn't break loose if the time on the server is way off, worst that can happen is that packages will be installed that normally wouldn't because they're too new.

I'll create a FlySpray task with a link to this thread and the updated patch for Pacman 2.9.

Edit: The task can be found here

LavaPunk · 2004-09-19 16:14:33

Personally I don't feel arch can spare any devs for this sort of project. The subject of an "old" repo, having all packages go through the "testing" repo, and even having pacman download only packages marked "X" days old has been gone over multiple times on the boards. I feel that part of arch is keeping a bleeding edge system, and running everything through testing breaks the "rolling release" idea, not to mention how much of a pain it would be. Almost every package has no problems, and so while everyone once in a while a package will have a second or third pkgrelease (adding a -2 or -3 respectively) this has never bothered me.

If you are worried about this you can do this yourself. Just don't do a daily "pacman -Syu." Instead run it once a week in the early morning after the new packages have been around a while. Or if you see a big upgrade coming (ie gcc) don't upgrade the first day if you're so worried about it. Personally I do not do either of these, and my system has never had any major problems. If there is a package coming that will cause widespread problems it is first put into "unstable" or "testing" prior to it's release into current/extra. If after a package is released into current/extra and it has dire consequences it is pulled and the older version is re-released until the problems can be ironed out. Finally don't forget that unless you clear your cache like an old women cleans her house you probably have the old package on your system so you can rollback onto that instead.

IMHO Arch doesn't have the manpower to spare for these to be implemented, and they really break Arch's ideals.

i3839 · 2004-09-19 17:44:41

Errm, you seem to totally miss the idea.

The UpgradeDelay has zero maintenance overhead, there is no special repository whatsoever. All it says is "upgrade only packages that are at least X days old". That means if there's a new package update, and you have UpgradeDelay=7, then it will be installed one week later. If that package turns out to be totally broken, and they release a new version within those 7 days, then you don't upgrade to the first one, nor the new one. You wait another 7 days, check if there's a new update, if not, install it. You never installed the broken version, isn't that nice?

The idea is that packages that are older are more stable, how buggier the package, how sooner it will be replaced with a new version, that's the idea. The only thing you need to do this is having the time of the package, and that can be simply the mtime of the files in the database.

This is a rolling update delay implementation, avoiding the need for a seperate stable branch.

The problem is that you can't do it yourself, because if you do -Syu you just get a list of all packages that need updating. If a package is as old as your last update, or one day is impossible to tell.

You propose to first break it, and then fix the mess, this way people can choose to skip the broken packages.

You don't need manpower to implement the upgrade delay idea, I already wrote a (as far as I know) working patch. And if you don't want it, then don't use it. But give the people that don't want to be extremely bleeding edge a way to have more stability.

Don't say that this idea goes against Arch's ideals if you don't understand what the idea actually is.

LavaPunk · 2004-09-19 20:30:50

I understood the basic idea flawlessly and most of my arguments were not directed at your idea, but instead at testing and old repository ideas. But since you insist:

The UpgradeDelay has zero maintenance overhead, there is no special repository whatsoever.

How does your script check how old a package is? Where does it connect to find a release date? Is it just running a diff of the date that each package was added off the main server?

The idea is that packages that are older are more stable, how buggier the package, how sooner it will be replaced with a new version, that's the idea.

I understand your sentiments, and that's why I said you could upgrade less often and do it early in the morning. I still feel that would protect you against 99% of major problems, but I can see that some people are too lazy to take a look at what needs to be updated. It's less trouble to let pacman deal with it. From a security standpoint I still prefer being bleeding edge though....

You propose to first break it, and then fix the mess, this way people can choose to skip the broken packages.

You lost me here... You mean that I'm "proposing" we do what Arch is currently doing? If everyone adopts your scheme how will we find out which packages have problems? Your scheme is no different than running everything through our testing repository then. Only a few people would be testing the bleeding edge which you are assuming is unstable.

You don't need manpower to implement the upgrade delay idea, I already wrote a (as far as I know) working patch. And if you don't want it, then don't use it. But give the people that don't want to be extremely bleeding edge a way to have more stability.

All I said was that I didn't think your idea should be implemented at the cost of the developers time. As you said you already wrote a working patch, but then Arch as a community must support this...

Don't say that this idea goes against Arch's ideals if you don't understand what the idea actually is.

Taken from the "about" section of the website (http://www.archlinux.org/about.php)

We (arch linux) try to stay fairly bleeding edge, and typically have the latest stable versions of software.

I take that to mean that we run the most current software as it is released by the respected parties as "stable." We are trusting that releases are not released as "stable" unless they are indeed stable.

I didn't mean for this to evolve into a flame war, which from reading your post, and mine, it seems to have become. I was just voicing my ideas/objections. I like to stay current and feel Arch does this very well without substituting stability for new features. I've found that with the (semi-recent) addition of the testing repository the stability of Arch as a whole has improved. Judging from other posts (ie this one:http://bbs.archlinux.org/viewtopic.php?t=6841&highlight=testing) there isn't an overwhelming call for a slower release schedule. It is my opinion that an open release is needed to find the bugs and report them, with your system this would be very difficult. The devs don't have hundreds of machines to test everything on and so when there are problems they work to correct them asap. It is my opinion that the arch philosophy is very much "let it be fixed upstream" and the current setup reflects this.

xerxes2 · 2004-09-19 20:48:25

When I came from mdk to arch I was to afraid to -syu the first month, so this sounds like a pretty good idea.

First throw core packages like kernel, x-server, glibc etc in Testing.
After they been in Testing for a few days and everything seems ok, move them to current.
And for the newbies and others that want to be "safe" , use a few extra days delay.

LavaPunk · 2004-09-19 21:22:18

After they been in Testing for a few days and everything seems ok, move them to current.

Ah but you missed my point. That's how it works now. Big updates are first put into testing. Xorg was, but no one uses the testing repository. Xorg sat in testing for three days but only a few bug reports were filed, all by tpowa. If we adopt this system then even LESS bugs will be filed as even LESS people will be using the packages initially. If all most of our users adopt this plan then we will be right back where we started.

I found my information here: http://bbs.archlinux.org/viewtopic.php? … c&start=15

i3839 · 2004-09-19 21:24:20

This is no flamewar, that's when we start throwing stuff at eachother. :-)

Your arguments are valid for the testing and old repository ideas yes, but I thought you meant the update delay, because that's what this thread is about, your arguments belong more in the previous thread where this one split off from, hence the confusion.

LavaPunk wrote:

How does your script check how old a package is? Where does it connect to find a release date? Is it just running a diff of the date that each package was added off the main server?

The source is above, but here's how I do it: I use the modification time of the pkgbuild (the files in the database get the same mtime as the pkgbuild with my gensync patch).

I understand your sentiments, and that's why I said you could upgrade less often and do it early in the morning. I still feel that would protect you against 99% of major problems, but I can see that some people are too lazy to take a look at what needs to be updated.

I don't upgrade often and almost always hand pick the packages I do want to update. To avoid this hassle I wrote that patch, because it basically does what I do now by hand. I don't see the advantage of updating in the morning though (and the Earth is round, so which morning?). It irritates me to download a big package and find out that it's updated again some days later because of some silly mistake. If you have a very fast connection that won't bother you much of course.

From a security standpoint I still prefer being bleeding edge though....

Security is a valid argument. It could be solved by giving security updates a false old mtime to force an update. Or let people do security updated by hand. Or something else.

If everyone adopts your scheme how will we find out which packages have problems? Your scheme is no different than running everything through our testing repository then. Only a few people would be testing the bleeding edge which you are assuming is unstable.

Most people want to be bleeding edge, so I don't think new packages won't get enough users to test them properly. If everyone would have some same default UpgradeDelay time then it won't make sense of course, but the default will be zero and people can set it to whatever value they want.

As you said you already wrote a working patch, but then Arch as a community must support this...

It's a very local feature that is no one in the way if you don't use it. It hardly complicates Pacman, it doesn't change the DB format, it has no side-effects. It has less impact than the total download size option. All it does is giving people more choice, that's why I can't see how people can be against this feature.

We (arch linux) try to stay fairly bleeding edge, and typically have the latest stable versions of software.

The upgrade delay feature doesn't change that. All what changes is that the value of "fairly" is adjustable now.

I take that to mean that we run the most current software as it is released by the respected parties as "stable." We are trusting that releases are not released as "stable" unless they are indeed stable.

That won't change. But if it turns out that there's a critical bug and a new version comes, then not everyone had the bad version installed. Also even if the package is really stable, a little mistake in the install script or pkgbuild can spoil the fun.

I was just voicing my ideas/objections.

That's fine, continue doing that.

I don't ask for slower release schedules or whatsoever, or any other policy change. I don't want that everyone is going to use an UpdateDelay of 2 weeks, if everyone would do that then this whole idea would be wrong. It's just a way to make people that care slightly more about stability than bleeding edge happy. You won't hear me asking for a seperate stable repository. In short, almost nothing changes, especially in practice, because the people that will most likely use this feature already don't upgrade blindly.

It is my opinion that the arch philosophy is very much "let it be fixed upstream" and the current setup reflects this.

Yes, the delay works for both bugs in Arch packages and bugs in the programs. The whole testing repository goes against the above philosophy though. I would be tempted to get rid of it and let UpgradeDelay handle it.

It would be nice that in the future you could add "pacman -Syu" to cron without ever being afraid of messing up your system.

My posts seem to become scarily big, so my next replies won't be so detailed anymore.

i3839 · 2004-09-19 21:33:29

LavaPunk wrote:

Xorg sat in testing for three days but only a few bug reports were filed, all by tpowa. If we adopt this system then even LESS bugs will be filed as even LESS people will be using the packages initially. If all most of our users adopt this plan then we will be right back where we started.

That's why I would get rid of the testing repo, especially if it doesn't work currently. If you have testing then you move it to current when you think that it works, the initial testing is already done, so there should be no need for a lot of users testing it anymore. So the problem is basically that not enough people use testing?

A update delay won't change that, because obviously such people won't use testing now. If you on the other hand get rid of testing and say that packages less than 3 days old can be considered "testing" then you would get a lot of more initial users. Big bugs are easier to find than smaller ones, how more broken the package how sooner you'll find out and post a fixed version. You also need less users to find big bugs, so it all fits nicely IMHO.

LavaPunk · 2004-09-19 21:54:47

Well no worries, Judd agrees with you guys. He accepted the feature request and I assume it will be incorporated in the near future. I can see how this will be nice for people who want to setup their boxes to update as a cron job. This will be very handy for them.

I still hold true in my belief that it will make it harder to find bugs as many people will adopt your system of waiting a few days once Arch has a small blurp in a package release. Oh well, we will see

i3839 · 2004-09-19 22:25:26

We'll see. If that happens then testing will lose all it's value, so then they could get rid of it, making things simpler. Look it from the bright side: The ftp servers will get lower peak loads because the downloading will be spread more even caused by different UpgradeDelay settings.

Xentac · 2004-09-20 00:24:08

It's doubtful that testing will go away, it has more uses than just strictly testing packages that may have problems.

A good example is packages that break backwards compatibility. The recent readline upgrade was such a case. A whole bunch of packages had to be rebuilt because readline's SONAME changed. Readline was initially added to testing and all rebuilds were put there first. Then they could all be graduated to their repos at once.

Oh wait... you didn't notice that, did you?

sarah31 · 2004-09-20 04:25:07

well this is all fine an dandy except that having upgrade delay features only encourages sloppy package releasing.

it seems obvious to me that there is no desire of the developers to address the problem of hasty releases.

i3839 · 2004-09-20 16:24:30

How worse the package quality how higher people will set the upgrade delay value, but that doesn't mean it encourages the devs to make sloppy releases, it just eases the pain for some when that happens. There will be enough irritated users left.

Even if the Arch's devs are perfect, if the upstream package was sloppy then a perfect pkgbuild won't save anyone. I don't know if you want all package makers to test the new version thoroughly before making a package, but IMHO that should be the upstream dev's responsibility, especially for minor updates.

If there are hasty, sloppy releases then that should be fixed seperately (e.g. if the dev makes too many broken packages someone else will become the maintainer of that package).

As for major library updates, I would handle that specially. Instead of rebuilding all packages which use the new version, just leave the old, working one until there are no packages that use it anymore. That way you can gradually replace all programs when they have a new version. Such versions are also more likely to work with the new lib. This can also be done for other programs that can live with multiple versions at once installed without problems, like gcc.

sarah31 · 2004-09-20 20:29:49

it isn't necessarily a matter of time making devs less sloppy but having a set standard for a package sitting in testing will increase the possiblilty that buggy pieces of dung don't end out in current and create havoc for everyone .

personally I don't have big issues with major upgrades but that is because i have learned that to upgrade right away is often a big faux pas in arch. many "veterans" know this and it is exactly this sloppiness that has dogged arch throughout it's history.

roll-backs are sloppy measures to bandaid obvious and critical mistakes. Standards for downstream releasing of packages SHOULD be considered instead of saying "well you can use roll-back when we screw up". it is not a matter of being perfect it is a matter of being smarter.

if a dev releases trash into testing then they have far more time to deal with it there than taking all the complaints of users for dumping it into current. ....

... i guess this is a losing philosopy on my part, but one I will continue to support and believe. you do not need to look far to find people that gave up on arch or have been frustrated with sloppy packaging in the past.

...yes i even did it. thankfully arch was much smaller then. now it isn't and what was a minor but pervailing issue has grow to epic proportions now.

dtw · 2004-09-26 20:43:43

i like the assumption that the time in testing is proportional to the amount of testing the package receives

i think this is a good idea (re: the original topic) as sarah said, people with abit of nous have learned not to upgrade straight away - but the prob with that is other things can break and you get idiots filing bug reports. why is everyone looking at me? anyway...

my ignorepkg list? imagemagick (i think it may be ok now), libcroco, gcc (still not made that step)

i think it is almost clever that most arch testing is done inadvertantly by normal users who -Su and get some dodge packages installed on their system - it soon brings the bugs out.

it's a weird one - however, Arch is easily the best distro i have used!

Arch Linux

#1 2004-09-19 09:49:50

Bleeding-edge, but X days old

#2 2004-09-19 13:04:07

Re: Bleeding-edge, but X days old

#3 2004-09-19 13:19:16

Re: Bleeding-edge, but X days old

#4 2004-09-19 13:20:05

Re: Bleeding-edge, but X days old

#5 2004-09-19 13:29:04

Re: Bleeding-edge, but X days old

#6 2004-09-19 14:29:17

Re: Bleeding-edge, but X days old

#7 2004-09-19 14:38:03

Re: Bleeding-edge, but X days old

#8 2004-09-19 14:39:40

Re: Bleeding-edge, but X days old

#9 2004-09-19 15:42:20

Re: Bleeding-edge, but X days old

#10 2004-09-19 16:14:33

Re: Bleeding-edge, but X days old

#11 2004-09-19 17:44:41

Re: Bleeding-edge, but X days old

#12 2004-09-19 20:30:50

Re: Bleeding-edge, but X days old

#13 2004-09-19 20:48:25

Re: Bleeding-edge, but X days old

#14 2004-09-19 21:22:18

Re: Bleeding-edge, but X days old

#15 2004-09-19 21:24:20

Re: Bleeding-edge, but X days old

#16 2004-09-19 21:33:29

Re: Bleeding-edge, but X days old

#17 2004-09-19 21:54:47

Re: Bleeding-edge, but X days old

#18 2004-09-19 22:25:26

Re: Bleeding-edge, but X days old

#19 2004-09-20 00:24:08

Re: Bleeding-edge, but X days old

#20 2004-09-20 04:25:07

Re: Bleeding-edge, but X days old

#21 2004-09-20 16:24:30

Re: Bleeding-edge, but X days old

#22 2004-09-20 20:29:49

Re: Bleeding-edge, but X days old

#23 2004-09-26 20:43:43

Re: Bleeding-edge, but X days old

Board footer