New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Need a luarocks upgrade command to upgrade installed rocks #22

Open
agladysh opened this Issue Jan 4, 2011 · 10 comments

Comments

Projects
None yet
8 participants
@agladysh

agladysh commented Jan 4, 2011

No description provided.

@petsagouris

This comment has been minimized.

Show comment
Hide comment
@petsagouris

petsagouris Jan 4, 2011

This is a must, but my head spins...

How would LR handle bad results, conflicts, bad rocks...?

Since we are talking batch rock actions, would there be any sense in an option to purge all rocks from the system ?

petsagouris commented Jan 4, 2011

This is a must, but my head spins...

How would LR handle bad results, conflicts, bad rocks...?

Since we are talking batch rock actions, would there be any sense in an option to purge all rocks from the system ?

@agladysh

This comment has been minimized.

Show comment
Hide comment
@agladysh

agladysh Jan 4, 2011

  1. Banish the misfeature with multiple installed versions of the same rock.
  2. A. If when upgrading user did not said --only-from: Check all available rock repositories for each installed rock.
  3. B. Otherwise: Check only specified repositoryfor each installed rock.
  4. Determine maximum found version.
  5. When all rocks are checked, filter out not updated rocks.
  6. Add necessary dependencies.
  7. Uninstall old versions for everything in the list. Install new versions, calling necessary hooks.
  8. If there are some rocks that were not manually installed (but brought as dependencies), and they are dependencies no longer, suggest user to autoremove them.

Purge all command rocks makes sense — I need it rather often. Please create a separate ticket.

agladysh commented Jan 4, 2011

  1. Banish the misfeature with multiple installed versions of the same rock.
  2. A. If when upgrading user did not said --only-from: Check all available rock repositories for each installed rock.
  3. B. Otherwise: Check only specified repositoryfor each installed rock.
  4. Determine maximum found version.
  5. When all rocks are checked, filter out not updated rocks.
  6. Add necessary dependencies.
  7. Uninstall old versions for everything in the list. Install new versions, calling necessary hooks.
  8. If there are some rocks that were not manually installed (but brought as dependencies), and they are dependencies no longer, suggest user to autoremove them.

Purge all command rocks makes sense — I need it rather often. Please create a separate ticket.

@felipedaragon

This comment has been minimized.

Show comment
Hide comment
@felipedaragon

felipedaragon Mar 14, 2014

This would be similar to "apt-get upgrade", right? I think it would be a cool addition.

felipedaragon commented Mar 14, 2014

This would be similar to "apt-get upgrade", right? I think it would be a cool addition.

@jiyinyiyong

This comment has been minimized.

Show comment
Hide comment
@jiyinyiyong

jiyinyiyong May 16, 2014

+1 , trully need this one.

jiyinyiyong commented May 16, 2014

+1 , trully need this one.

@hishamhm

This comment has been minimized.

Show comment
Hide comment
@hishamhm

hishamhm Sep 10, 2014

Member

For future reference:

This commit introduces the luarocks list --outdated command, which does what you expect:

e5cd7a9

And here we have a discussion about the difficulties around an upgrade command:

http://article.gmane.org/gmane.comp.lang.lua.general/112719

Also, the luarocks purge is also available by now.

Member

hishamhm commented Sep 10, 2014

For future reference:

This commit introduces the luarocks list --outdated command, which does what you expect:

e5cd7a9

And here we have a discussion about the difficulties around an upgrade command:

http://article.gmane.org/gmane.comp.lang.lua.general/112719

Also, the luarocks purge is also available by now.

@felipedaragon

This comment has been minimized.

Show comment
Hide comment
@felipedaragon

felipedaragon Sep 10, 2014

cool! I still have to get more familiar with all the LR aspects.

felipedaragon commented Sep 10, 2014

cool! I still have to get more familiar with all the LR aspects.

@Asmageddon

This comment has been minimized.

Show comment
Hide comment
@Asmageddon

Asmageddon Oct 10, 2014

Regarding that discussion, I imagine that dependencies could simply be installed differently from packages the user requests and be allowed to be installed in multiple versions, perhaps somehow linked to individual packages that need them, if that's even possible.

Asmageddon commented Oct 10, 2014

Regarding that discussion, I imagine that dependencies could simply be installed differently from packages the user requests and be allowed to be installed in multiple versions, perhaps somehow linked to individual packages that need them, if that's even possible.

@mpeterv

This comment has been minimized.

Show comment
Hide comment
@mpeterv

mpeterv Nov 4, 2016

Member

@hishamhm I think it would be great to decide on upgrade functionality interface and possibly on changing default install behavior for Luarocks 3.

Member

mpeterv commented Nov 4, 2016

@hishamhm I think it would be great to decide on upgrade functionality interface and possibly on changing default install behavior for Luarocks 3.

@Abhinand-p

This comment has been minimized.

Show comment
Hide comment
@Abhinand-p

Abhinand-p Mar 19, 2017

@catwell There should be a mechanism to embed old rock into new at least logically. Some transformation parameter check to be performed. If developer go on building new rock without parameter normalization required for semantic level, then we cannot provide up-gradation. Dependency chains can be logged in a data file. More linking types are investigated for old to new, less work will be for user.

Abhinand-p commented Mar 19, 2017

@catwell There should be a mechanism to embed old rock into new at least logically. Some transformation parameter check to be performed. If developer go on building new rock without parameter normalization required for semantic level, then we cannot provide up-gradation. Dependency chains can be logged in a data file. More linking types are investigated for old to new, less work will be for user.

@Abhinand-p

This comment has been minimized.

Show comment
Hide comment
@Abhinand-p

Abhinand-p Mar 19, 2017

@catwell
A command to upgrade shall have the operation tree like:
1> Make dependency data file. (Automatic look up table of different functionalities)
2> Upload dependency data file. (Directories setting)
3> Partial build of virtual rock. (Query on server, buffer, retaining old and new versions in a amicable format)
4> Upgrade interface (GUI also required)
5> Upgrade command (Repository path)

Abhinand-p commented Mar 19, 2017

@catwell
A command to upgrade shall have the operation tree like:
1> Make dependency data file. (Automatic look up table of different functionalities)
2> Upload dependency data file. (Directories setting)
3> Partial build of virtual rock. (Query on server, buffer, retaining old and new versions in a amicable format)
4> Upgrade interface (GUI also required)
5> Upgrade command (Repository path)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment