[arch-dev-public] pacman upgrade issue (was: ArchLinux [current] status)
On 5/9/07, Jason Chu <jason@archlinux.org> wrote:
On Wed, May 09, 2007 at 12:52:31PM -0500, Aaron Griffin wrote:
Jason, can you take this task on? I want to a) figure out a solution to the pacman upgrade issue b) deal with the package cleanup So I don't have huge amounts of time to spare at the moment.
I am also lacking in time. Can you explain the pacman upgrade issue a little better (there was a bug report about it at one point, right?)?
I will make sure something gets done, but I doubt I'll be the one to do it.
Here we go. I was about to move pacman 3 to current last night and realized there is a minor show-stopper in the upgrade path. The way pacman 2.X works, when it finds an upgrade for itself, it removes _ALL_ additional targets from the list and adds pacman. At this point, deps have already been resolved. So, the new pacman depends on libdownload and libarchive. Clearing out the target list also removes these. So pacman will download pacman3, then try to install it, and fail because dependencies are missing. This is not a critical issue, as one can easilly -S those two, but it is not clean. When this moves to current, there will be many people with problems, and not everyone checks the news items / reads the forums. The use case will go as follows: pacman -Syu "New pacman is available, upgrade? [Y/n]" Y ...download pacman 3... Whoops, cannot find dependencies "libdownload" or "libarchive", failing "Hmmm, wtf?" pacman -S libdownload libarchive pacman -Syu Again, this is not critical, not fatal, and not a big deal, it is just messy. I want to figure out if there is some good way to do this, but I do not think so.
2007/5/9, Aaron Griffin <aaronmgriffin@gmail.com>:
On 5/9/07, Jason Chu <jason@archlinux.org> wrote:
On Wed, May 09, 2007 at 12:52:31PM -0500, Aaron Griffin wrote:
Jason, can you take this task on? I want to a) figure out a solution to the pacman upgrade issue b) deal with the package cleanup So I don't have huge amounts of time to spare at the moment.
I am also lacking in time. Can you explain the pacman upgrade issue a little better (there was a bug report about it at one point, right?)?
I will make sure something gets done, but I doubt I'll be the one to do it.
Here we go. I was about to move pacman 3 to current last night and realized there is a minor show-stopper in the upgrade path.
The way pacman 2.X works, when it finds an upgrade for itself, it removes _ALL_ additional targets from the list and adds pacman. At this point, deps have already been resolved.
So, the new pacman depends on libdownload and libarchive. Clearing out the target list also removes these. So pacman will download pacman3, then try to install it, and fail because dependencies are missing.
This is not a critical issue, as one can easilly -S those two, but it is not clean. When this moves to current, there will be many people with problems, and not everyone checks the news items / reads the forums.
The use case will go as follows: pacman -Syu "New pacman is available, upgrade? [Y/n]" Y ...download pacman 3... Whoops, cannot find dependencies "libdownload" or "libarchive", failing "Hmmm, wtf?" pacman -S libdownload libarchive pacman -Syu
Again, this is not critical, not fatal, and not a big deal, it is just messy. I want to figure out if there is some good way to do this, but I do not think so.
I think implementing a solution for this is a bit late now, and it may bring some new bug(s). Let's just announce the correct steps for upgrading pacman (again, bacause it was done some time ago) right now. -- Roman Kyrylych (Роман Кирилич)
On Wed, May 09, 2007 at 01:18:32PM -0500, Aaron Griffin wrote:
On 5/9/07, Jason Chu <jason@archlinux.org> wrote:
On Wed, May 09, 2007 at 12:52:31PM -0500, Aaron Griffin wrote:
Jason, can you take this task on? I want to a) figure out a solution to the pacman upgrade issue b) deal with the package cleanup So I don't have huge amounts of time to spare at the moment.
I am also lacking in time. Can you explain the pacman upgrade issue a little better (there was a bug report about it at one point, right?)?
I will make sure something gets done, but I doubt I'll be the one to do it.
Here we go. I was about to move pacman 3 to current last night and realized there is a minor show-stopper in the upgrade path.
The way pacman 2.X works, when it finds an upgrade for itself, it removes _ALL_ additional targets from the list and adds pacman. At this point, deps have already been resolved.
So, the new pacman depends on libdownload and libarchive. Clearing out the target list also removes these. So pacman will download pacman3, then try to install it, and fail because dependencies are missing.
This is not a critical issue, as one can easilly -S those two, but it is not clean. When this moves to current, there will be many people with problems, and not everyone checks the news items / reads the forums.
The use case will go as follows: pacman -Syu "New pacman is available, upgrade? [Y/n]" Y ...download pacman 3... Whoops, cannot find dependencies "libdownload" or "libarchive", failing "Hmmm, wtf?" pacman -S libdownload libarchive pacman -Syu
Again, this is not critical, not fatal, and not a big deal, it is just messy. I want to figure out if there is some good way to do this, but I do not think so.
Can we release a new version of pacman 2.X that downloads deps of pacman when it finds a pacman update? I don't know how much work this is. I was also going to suggest we just add the deps to a pkgrel bumped pacman 2.X, but you run into the same problem. Having the feature to download deps of pacman as well as pacman when doing the "New pacman is available" steps makes a lot of sense for situations like this in the future. Jason
On 5/9/07, Jason Chu <jason@archlinux.org> wrote:
On Wed, May 09, 2007 at 01:18:32PM -0500, Aaron Griffin wrote:
On 5/9/07, Jason Chu <jason@archlinux.org> wrote:
On Wed, May 09, 2007 at 12:52:31PM -0500, Aaron Griffin wrote:
Jason, can you take this task on? I want to a) figure out a solution to the pacman upgrade issue b) deal with the package cleanup So I don't have huge amounts of time to spare at the moment.
I am also lacking in time. Can you explain the pacman upgrade issue a little better (there was a bug report about it at one point, right?)?
I will make sure something gets done, but I doubt I'll be the one to do it.
Here we go. I was about to move pacman 3 to current last night and realized there is a minor show-stopper in the upgrade path.
The way pacman 2.X works, when it finds an upgrade for itself, it removes _ALL_ additional targets from the list and adds pacman. At this point, deps have already been resolved.
So, the new pacman depends on libdownload and libarchive. Clearing out the target list also removes these. So pacman will download pacman3, then try to install it, and fail because dependencies are missing.
This is not a critical issue, as one can easilly -S those two, but it is not clean. When this moves to current, there will be many people with problems, and not everyone checks the news items / reads the forums.
The use case will go as follows: pacman -Syu "New pacman is available, upgrade? [Y/n]" Y ...download pacman 3... Whoops, cannot find dependencies "libdownload" or "libarchive", failing "Hmmm, wtf?" pacman -S libdownload libarchive pacman -Syu
Again, this is not critical, not fatal, and not a big deal, it is just messy. I want to figure out if there is some good way to do this, but I do not think so.
Can we release a new version of pacman 2.X that downloads deps of pacman when it finds a pacman update? I don't know how much work this is.
The problem there is that in order for that to work, that 2.X release would need to remain in the repos for a while, to ensure that most users have an upgradeable version. If we put the new 2.X release out there for, say, a week, some users might miss the upgrade and run into the same issue.
Having the feature to download deps of pacman as well as pacman when doing the "New pacman is available" steps makes a lot of sense for situations like this in the future.
True, but that's just an issue of foresight. It took years to actually manifest as an issue, and even then it's rather minor.
Can we release a new version of pacman 2.X that downloads deps of pacman when it finds a pacman update? I don't know how much work this is.
The problem there is that in order for that to work, that 2.X release would need to remain in the repos for a while, to ensure that most users have an upgradeable version. If we put the new 2.X release out there for, say, a week, some users might miss the upgrade and run into the same issue.
Very true. Again we run into the problem of releasing quickly or releasing "stabley". We have to make a choice: keep back pacman 3 to make the upgrade smoother or move to pacman 3 and force some users to go hunting for a solution. Either way we choose people will be critical, so this is where applying it to some sort of goals comes in handy.
Having the feature to download deps of pacman as well as pacman when doing the "New pacman is available" steps makes a lot of sense for situations like this in the future.
True, but that's just an issue of foresight. It took years to actually manifest as an issue, and even then it's rather minor.
Sure, minor because there's a solution. Not a directly apparent solution but one that people could search for. Jason
2007/5/9, Jason Chu <jason@archlinux.org>:
Can we release a new version of pacman 2.X that downloads deps of pacman when it finds a pacman update? I don't know how much work this is.
The problem there is that in order for that to work, that 2.X release would need to remain in the repos for a while, to ensure that most users have an upgradeable version. If we put the new 2.X release out there for, say, a week, some users might miss the upgrade and run into the same issue.
Very true. Again we run into the problem of releasing quickly or releasing "stabley". We have to make a choice: keep back pacman 3 to make the upgrade smoother or move to pacman 3 and force some users to go hunting for a solution. Either way we choose people will be critical, so this is where applying it to some sort of goals comes in handy.
It would be nice if new Arch release will have pacman 3 (which will be soon). So let's not delay pacman3->current move -- Roman Kyrylych (Роман Кирилич)
On 5/9/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2007/5/9, Jason Chu <jason@archlinux.org>:
Can we release a new version of pacman 2.X that downloads deps of pacman when it finds a pacman update? I don't know how much work this is.
The problem there is that in order for that to work, that 2.X release would need to remain in the repos for a while, to ensure that most users have an upgradeable version. If we put the new 2.X release out there for, say, a week, some users might miss the upgrade and run into the same issue.
Very true. Again we run into the problem of releasing quickly or releasing "stabley". We have to make a choice: keep back pacman 3 to make the upgrade smoother or move to pacman 3 and force some users to go hunting for a solution. Either way we choose people will be critical, so this is where applying it to some sort of goals comes in handy.
It would be nice if new Arch release will have pacman 3 (which will be soon). So let's not delay pacman3->current move
Seconded.
On 5/9/07, Jason Chu <jason@archlinux.org> wrote:
Can we release a new version of pacman 2.X that downloads deps of pacman when it finds a pacman update? I don't know how much work this is.
The problem there is that in order for that to work, that 2.X release would need to remain in the repos for a while, to ensure that most users have an upgradeable version. If we put the new 2.X release out there for, say, a week, some users might miss the upgrade and run into the same issue.
Very true. Again we run into the problem of releasing quickly or releasing "stabley". We have to make a choice: keep back pacman 3 to make the upgrade smoother or move to pacman 3 and force some users to go hunting for a solution. Either way we choose people will be critical, so this is where applying it to some sort of goals comes in handy.
Yeah, but it's not like it's not apparent. pacman actually does fail with "X and Y are missing" even a casual user is able to say "hmmm, pacman -Ss X" to find the package. They will be confused, sure, but it's remedied quickly. Going off of precedent, I think we should just go with the news item and push to current - there have been a few major-ish changes in the past that did similar things, and we don't seem to have an easy way out of this. Can I get a consensus that posting a news item with an easy fix and pushing to current is a good idea? Dan, do you have any additional ideas (Simo had a few, I posted them in IRC last night)?
Can I get a consensus that posting a news item with an easy fix and pushing to current is a good idea? Dan, do you have any additional ideas (Simo had a few, I posted them in IRC last night)?
+1 Jason
Going off of precedent, I think we should just go with the news item and push to current - there have been a few major-ish changes in the past that did similar things, and we don't seem to have an easy way out of this.
Can I get a consensus that posting a news item with an easy fix and pushing to current is a good idea? Dan, do you have any additional ideas (Simo had a few, I posted them in IRC last night)?
I say post a news item on date X, with links to download the pacman update, and libraries, for a manual install. Wait a few days after posting the links, and *then* push it to the repository. This will give you a chance to have a few early adopters, and also a way to get word of mouth out before hand..so if people *do* get confused on the go live date, they can a) check the new site b) hop into irc and people will likely know about it right away c) have good messaging on the forums, as well as people knowing right away. I think the key is messaging *before* the push to current. Get the word out, and then do it a few days later... preferably on a weekend so as to not impact weekday business as much as possible (and give people more time to address the odd issue that may arise).
2007/5/9, eliott@cactuswax.net <eliott@cactuswax.net>:
Going off of precedent, I think we should just go with the news item and push to current - there have been a few major-ish changes in the past that did similar things, and we don't seem to have an easy way out of this.
Can I get a consensus that posting a news item with an easy fix and pushing to current is a good idea? Dan, do you have any additional ideas (Simo had a few, I posted them in IRC last night)?
I say post a news item on date X, with links to download the pacman update, and libraries, for a manual install. Wait a few days after posting the links, and *then* push it to the repository.
This will give you a chance to have a few early adopters, and also a way to get word of mouth out before hand..so if people *do* get confused on the go live date, they can a) check the new site b) hop into irc and people will likely know about it right away c) have good messaging on the forums, as well as people knowing right away.
I think the key is messaging *before* the push to current. Get the word out, and then do it a few days later... preferably on a weekend so as to not impact weekday business as much as possible (and give people more time to address the odd issue that may arise).
No need to put pacman files somewhere while they are in testing already. Users just temporarily uncomment and put [testing] section at the _end_ of rc.conf and then do pacman -S pacman :) -- Roman Kyrylych (Роман Кирилич)
I think the key is messaging *before* the push to current. Get the word out, and then do it a few days later... preferably on a weekend so as to not impact weekday business as much as possible (and give people more time to address the odd issue that may arise).
My thoughts exactly. His second day as an official dev and Cactus is already stealing my lines. :) - P
On 5/9/07, Paul Mattal <paul@mattal.com> wrote:
I think the key is messaging *before* the push to current. Get the word out, and then do it a few days later... preferably on a weekend so as to not impact weekday business as much as possible (and give people more time to address the odd issue that may arise).
My thoughts exactly.
His second day as an official dev and Cactus is already stealing my lines. :)
My name is Paul (I wanted to steal one too, and that's all I thought of)
On 5/9/07, Paul Mattal <paul@mattal.com> wrote:
I think the key is messaging *before* the push to current. Get the word out, and then do it a few days later... preferably on a weekend so as to not impact weekday business as much as possible (and give people more time to address the odd issue that may arise).
My thoughts exactly.
His second day as an official dev and Cactus is already stealing my lines. :)
My name is Paul
(I wanted to steal one too, and that's all I thought of)
haha! that made my day. :)
On 5/9/07, Paul Mattal <paul@mattal.com> wrote:
I think the key is messaging *before* the push to current. Get the word out, and then do it a few days later... preferably on a weekend so as to not impact weekday business as much as possible (and give people more time to address the odd issue that may arise).
My thoughts exactly.
News posted. http://archlinux.org/news/320/
2007/5/10, Aaron Griffin <aaronmgriffin@gmail.com>:
On 5/9/07, Paul Mattal <paul@mattal.com> wrote:
I think the key is messaging *before* the push to current. Get the word out, and then do it a few days later... preferably on a weekend so as to not impact weekday business as much as possible (and give people more time to address the odd issue that may arise).
My thoughts exactly.
News posted. http://archlinux.org/news/320/
BTW, won't pacman pickup deps after doing -Sw libdownload libarchive instead of -S? -- Roman Kyrylych (Роман Кирилич)
On 5/9/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2007/5/10, Aaron Griffin <aaronmgriffin@gmail.com>:
On 5/9/07, Paul Mattal <paul@mattal.com> wrote:
I think the key is messaging *before* the push to current. Get the word out, and then do it a few days later... preferably on a weekend so as to not impact weekday business as much as possible (and give people more time to address the odd issue that may arise).
My thoughts exactly.
News posted. http://archlinux.org/news/320/
BTW, won't pacman pickup deps after doing -Sw libdownload libarchive instead of -S?
No. The problem is that when it strips everything from the list of packages to install, it has already done the dep resolution, it's not about downloading.
On Wed, May 09, 2007 at 11:58:21AM -0700, eliott@cactuswax.net wrote:
I think the key is messaging *before* the push to current. Get the word out, and then do it a few days later... preferably on a weekend so as to not impact weekday business as much as possible (and give people more time to address the odd issue that may arise).
Ok, then let's get the news items up tonight or tomorrow and set it loose in current around Saturday night. This isn't the first time we've done the news item thing, and we took some flak for it before, but that's life... now isn't it? :) -S
On Wed, May 09, 2007 at 01:18:32PM -0500, Aaron Griffin wrote:
On 5/9/07, Jason Chu <jason@archlinux.org> wrote:
On Wed, May 09, 2007 at 12:52:31PM -0500, Aaron Griffin wrote:
Jason, can you take this task on? I want to a) figure out a solution to the pacman upgrade issue b) deal with the package cleanup So I don't have huge amounts of time to spare at the moment.
I am also lacking in time. Can you explain the pacman upgrade issue a little better (there was a bug report about it at one point, right?)?
I will make sure something gets done, but I doubt I'll be the one to do it.
Here we go. I was about to move pacman 3 to current last night and realized there is a minor show-stopper in the upgrade path.
The way pacman 2.X works, when it finds an upgrade for itself, it removes _ALL_ additional targets from the list and adds pacman. At this point, deps have already been resolved.
So, the new pacman depends on libdownload and libarchive. Clearing out the target list also removes these. So pacman will download pacman3, then try to install it, and fail because dependencies are missing.
Workaround: static-only pacman3 build? Jürgen
On Wed, May 09, 2007 at 09:09:20PM +0200, Jürgen Hötzel wrote:
Workaround: static-only pacman3 build?
That was one of the ideas Aaron and I rolled around on IRC last night, but it has the same problem as fixing pacman2... some people will inevitably miss the timeframe when we distribute pacman3 static compiled and will still hit the issue someday. -S
Aaron Griffin schrieb:
Here we go. I was about to move pacman 3 to current last night and realized there is a minor show-stopper in the upgrade path.
The way pacman 2.X works, when it finds an upgrade for itself, it removes _ALL_ additional targets from the list and adds pacman. At this point, deps have already been resolved.
So, the new pacman depends on libdownload and libarchive. Clearing out the target list also removes these. So pacman will download pacman3, then try to install it, and fail because dependencies are missing.
I knew that :) I thought you knew, too.
The use case will go as follows: pacman -Syu "New pacman is available, upgrade? [Y/n]" Y ...download pacman 3... Whoops, cannot find dependencies "libdownload" or "libarchive", failing "Hmmm, wtf?" pacman -S libdownload libarchive pacman -Syu
There was the suggestion of pushing a fixed pacman2 out there. I hate it. pacman2 is so buggy with dependencies and just pushing out a new release to make the update smoother appears stupid. And it will confuse people. And it will be a waste of time to change the pacman2 codebase again. We need pacman3 now and I suggest we just move it. If we post a news item, an item in the Announcements forum and add a repeated irc message, people will pick it up.
participants (8)
-
Aaron Griffin
-
eliott＠cactuswax.net
-
Jason Chu
-
Jürgen Hötzel
-
Paul Mattal
-
Roman Kyrylych
-
Simo Leone
-
Thomas Bächler