Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
en:docs:distribution [2014/05/23 03:27] – external edit 127.0.0.1 | en:docs:distribution [2016/02/04 01:04] (current) – [Package management] valerius | ||
---|---|---|---|
Line 11: | Line 11: | ||
=== Package sources frontend === | === Package sources frontend === | ||
- | * Also, a tool like eCoShop | + | * Also, a tool like eCoMarket |
* it must handle different package sources, like | * it must handle different package sources, like | ||
* files in the current directory | * files in the current directory | ||
* special directory layouts (on the current machine, or on remote http or ftp server), like diskette images with bundles (as used by IBM OS/2 distributions so, the installer will be capable to install old IBM OS/2 distributions as well) | * special directory layouts (on the current machine, or on remote http or ftp server), like diskette images with bundles (as used by IBM OS/2 distributions so, the installer will be capable to install old IBM OS/2 distributions as well) | ||
- | * other directory layouts, like APT or RPM repositories | + | * other directory layouts, like APT or YUM repositories |
* different file transport protocols support, like ftp, http, etc, via plugins | * different file transport protocols support, like ftp, http, etc, via plugins | ||
* maybe, support for handling the different packages formats, other than WPI, because Netlabs, for example, prefer RPM's, so, it would be good to have support for them too, as they seem to be logical for ports from UNIX (but they are not suited well for native OS/2 applications). So, the support for the following formats would be desirable: | * maybe, support for handling the different packages formats, other than WPI, because Netlabs, for example, prefer RPM's, so, it would be good to have support for them too, as they seem to be logical for ports from UNIX (but they are not suited well for native OS/2 applications). So, the support for the following formats would be desirable: | ||
Line 22: | Line 22: | ||
* pack/ | * pack/ | ||
* the package source frontend will handle different package types via special plugins (or backends), and invoke different tools when installing packages (invoke WIC, UNZIP, UNPACK or RPM) | * the package source frontend will handle different package types via special plugins (or backends), and invoke different tools when installing packages (invoke WIC, UNZIP, UNPACK or RPM) | ||
- | * maybe, even, the possibility to create the decentralised network of package repositories is needed -- this will allow to use any nearest mirror, or use another mirror if the main mirror is down. Even we could try to create the repositories network on Peer-to-Peer basis ;) | + | * maybe, even, the possibility to create the decentralised network of package repositories is needed -- this will allow to use any nearest mirror, or use another mirror if the main mirror is down. Even we could try to create the repositories network on Peer-to-Peer basis ;) (Use Bittorrent or any other protocol via a separate plugin,like the one for ftp/http) |
=== WarpIN enhancements === | === WarpIN enhancements === | ||
Line 28: | Line 28: | ||
* The enhancements to WarpIN should include: | * The enhancements to WarpIN should include: | ||
* " | * " | ||
- | * Support for simultaneously existing versions of different packages with libraries, which are needed for different applications | + | * Support for simultaneously existing versions of different packages with libraries, which are needed for different applications |
* Maybe, " | * Maybe, " | ||
* Coexistence of several package trees, which are updated separately, and do not influence other trees -- some analogies with source code repositories with branches | * Coexistence of several package trees, which are updated separately, and do not influence other trees -- some analogies with source code repositories with branches |