General Features/Ideas
The general features of this software were the following:
- handle multiple software repositories
- handle at least two levels of repositories (stable and unstable)
- download software from repositories
- install software (directly from the internet or from a package on the ifs)
- install and compile software from source packages
- query repositories for software
- update software
For compilation there should be global settings and settings on a per package base.
Also i would like to put ALL copybooks of prototypes for exported procedures into a separate source file (f. e. QCPYSRC) so a developer can more easily use them. But that would mean that the package maintainer must look out for duplicate names.
Service programs and modules flagged for export should be added to a general binding directory. There the package maintainer must watch out for duplicated names of exports.
The other option to avoid duplicate names would be to make source files for copybooks and binding directories per package but i think that would not ease the development (which is one thing i am after with this project).
Any further ideas?
--imported--
kind of change management-ish
it would be nice if you could design in at least three from the beginning. I would like to see:
it would be nice if you could design in at least three from the beginning. I would like to see:
repository levels
I don't think we need that many levels. For example I don't think we need a development level because the developer will test on his own system and won't upload any pre-alpha/alpha software. We need only beta software level (unstable) and production software level (stable).
But it shouldn't be too hard to keep it configurable.
My 2 cents.
Mihael
I don't think we need that many levels. For example I don't think we need a development level because the developer will test on his own system and won't upload any pre-alpha/alpha software. We need only beta software level (unstable) and production software level (stable).
But it shouldn't be too hard to keep it configurable.
My 2 cents.
Mihael
copy books
Perhaps the copy books should be stored in a place like /usr/local/include. Every package could have their own directory for example the DSM package could have a folder /usr/local/include/dsm where its prototypes are stored.
A program would then include the copybooks with something like /include 'dsm/dsm_h.rpgle' . And on the compile you could specifiy the include directory /usr/local/include . That would prevent the clashing of names. Package names must be unique but the copy books could have the same name.
I haven't tested it all yet but I think it should work.
Perhaps the copy books should be stored in a place like /usr/local/include. Every package could have their own directory for example the DSM package could have a folder /usr/local/include/dsm where its prototypes are stored.
A program would then include the copybooks with something like /include 'dsm/dsm_h.rpgle' . And on the compile you could specifiy the include directory /usr/local/include . That would prevent the clashing of names. Package names must be unique but the copy books could have the same name.
I haven't tested it all yet but I think it should work.
Seperate packages for source, objects and headers/prototypes
Should we have seperate packages for compiled binaries, copybooks/header files and sources like on so many linux systems?
Should we have seperate packages for compiled binaries, copybooks/header files and sources like on so many linux systems?