Package Manager
Moderator: Moderator Team
Wow, since i posted that to the mailing list we got lots of postings here. I hope that you don't mind that I haven't read everything right now.
I was told to create a wiki page, on the mailing list. So here it is: http://mok.lvcm.com/cgi-bin/reactos/ros ... ageManager. Fell free to correct grammar mistakes and so on. And to to add you own ideas and thought. But please try not to start a edit war.
I was told to create a wiki page, on the mailing list. So here it is: http://mok.lvcm.com/cgi-bin/reactos/ros ... ageManager. Fell free to correct grammar mistakes and so on. And to to add you own ideas and thought. But please try not to start a edit war.
Where do you want ReactOS to go today ?
-
- Posts: 48
- Joined: Thu Dec 02, 2004 11:42 am
- Location: Italy
- Contact:
these aren't two different opinions...in fact can be used wxwindows or gtk stuff, and, in every case when ros will be ready to used mono will have completed all windows.forms and drawing stufffrik85 wrote:daniele_dll wrote:a little question...this night i was thinking about the possibility to use C# with mono instead of C\C++ this becase there will be less bugs and more features...can be a good idea? :DDDTwo complete different opinions in two days ???daniele_dll - http://www.reactos.com/forum/viewtopic.php?t=112 wrote:mono is a wonderful project but do not support (now) system.windows.forms and system.drawing and similar...there are, hovewer, a work in progress but i think that they will need many many time
http://www.mono-project.com/contributing/winforms.html
In my opinion the Ros Packet Manager should be written in C/C++ or XML/XSL.
No dependences (like .NET, Mono, VB-Runtime, DLLs, etc) required!
---
dr. fred i can help this project in many ways
i work mainly with network stuff and i've used many times minixml and libxml
i know very well php and mysql and i can help too if we decide to use an installer, i can write templates for installer
I'm glad that you want to help Please enter your names to the wiki page.frik85 wrote:I also could help with XML experience and writing a script engine (new script language or basic/vbscript).NetSlayer wrote:I could help to program a graphical package manager in C.
IMHO porting such a app is as much work as writing a new one.If we will use XML based package manager we can just port with a little changes the one that is used in gentoo linux.
There can be a option so that you can choose the location of the xml file.I think that we will need more than one XML tree.
Nullsoft is a delphi app too, but i don't think that this is the problem. The problem that we (or I) don't know if they support downloading and unzipping an external file.there are packages like nullsoft installer and innosetup that are very interesting ...
@C# and .Net
Ros Devs barely accept C++ code. So you better forget about that.
Many? I only know urlmon (some thing like that). And i don't think that it is implemented right now.to download packages isin't necessary wget Smile windows has many components to work with remote servers like http and ftp
That is true. We can maybe use a expacted download time or something.and however we need to display a progress bar or something of similar so is necessary that download system is integrated into the app os however into a library that we recall
I hope that I have answered to every thing I should answer to. I'm very tiered today. So don't wonder, if something I wrote is wrong or unreadble.
[/quote]batch file support.
<= omg
I thought of batch files as scripts, too. But the problems are the progress bar and error reports.
Last edited by Dr. Fred on Sun Jan 02, 2005 5:33 pm, edited 1 time in total.
Where do you want ReactOS to go today ?
-
- Posts: 48
- Joined: Thu Dec 02, 2004 11:42 am
- Location: Italy
- Contact:
ok@C# and .NEt
Ros Devs barely accept C++ code. So you better forget about that.
download from web yes...unzipping i think yes tooNullsoft is a delphi app too, but i don't think that this is the problem. The problem that we (or I) don't know if they support downloading and unzipping an external file.
however nsis is expandible using C or C++ (and delphi)
nsis support too the possibility to do calls directly to dlls
Nullsoft supports downloading and supports compression (ZLib, BZip2, LZMA) and already works in reactos (for a long time).
Scripting might be useful and can help install packages that wont or cant use nullsoft (or whatewer we choose).
(I tested Regina which is Rexx interpreter and it works under ReactOS (and it was faster than on my Win98) but I guess we should support scripting only through plugins)
I think it will be easier to maintain it than one big XML file. We can just create directory tree (instead of XML tree). And also we can just use XML with custom extension (or make a zip file with XML and other necessary files) - with that feature it will be easy to have also both web version of the package list and local one.denzil have more xml is a bad idea because will be a problem mantain all xml tree updates...
Scripting might be useful and can help install packages that wont or cant use nullsoft (or whatewer we choose).
(I tested Regina which is Rexx interpreter and it works under ReactOS (and it was faster than on my Win98) but I guess we should support scripting only through plugins)
The problem that we can't browse it without writing a parser for the http interface pages.We can just create directory tree (instead of XML tree).
That is just what we were talking about before, isn't it ?And also we can just use XML with custom extension
That would be harder to maintain.or make a zip file with XML and other necessary files
But we can do something else: We use a <include> tag. So that we can outsource some braches, when the tree get fuller.
We can have a dissusion about it a few more days and then make a vote on what solution we choose. (The forum has this neat future)I guess we should support scripting only through plugins
Where do you want ReactOS to go today ?
i talked a few months ago to apollo11 on irc about a package manager, he also recommended to use an xml file. As i don't know xml yet i did some script with wget.exe, unzip.exe and mkisofs.exe that does automatic download and installation of a few programs.
Biggest problems are for closed source programs like freeware etc:
1) They normally don't use .msi Standard and therefore don't use easy silent installation options (scriptable installation). 2) I think they won't repackage their application so that we can use it for some easy package manager - so i think. 3) New shareware programs are no more allowed to be kept for downloading, as there exist patches for slightly out of date versions.
Theses problem is not existant for open source applications, we are allowed to modify and repackage them (afaik).
Maybe my batch script can help in some way? It has still some errors but it should work on windows xp (supported applications: total cmd 5.51, scite, windows tetris, mandelbrot, xaos, abiword, irfanview, filezilla, nero 3020).
http://129.125.140.135/~ravelo/rosload.zip
Biggest problems are for closed source programs like freeware etc:
1) They normally don't use .msi Standard and therefore don't use easy silent installation options (scriptable installation). 2) I think they won't repackage their application so that we can use it for some easy package manager - so i think. 3) New shareware programs are no more allowed to be kept for downloading, as there exist patches for slightly out of date versions.
Theses problem is not existant for open source applications, we are allowed to modify and repackage them (afaik).
Maybe my batch script can help in some way? It has still some errors but it should work on windows xp (supported applications: total cmd 5.51, scite, windows tetris, mandelbrot, xaos, abiword, irfanview, filezilla, nero 3020).
http://129.125.140.135/~ravelo/rosload.zip
Thats a good idea!Dr. Fred - http://mok.lvcm.com/cgi-bin/reactos/roswiki?PackageManager wrote:I'm also thinking that the process should be divided into 3 parts: before/main/after (but not with that names). First all before parts are executed, than all main parts and finally all after parts. In the main part the script is not allowed to do anything that requires user interaction. So that the user can install lots of apps and does not have to sit in front of his Computer for durring the hole process.
I think the packet manager should support command line parameters.
e.g. "Silent mode": <paketmanager>.exe /s
So every system admin can update pcs with a special script.
e.g. "Expert mode": <paketmanager>.exe /e
So you can set more specific options.
-
- Posts: 48
- Joined: Thu Dec 02, 2004 11:42 am
- Location: Italy
- Contact:
And this is what leads us to another question: Do we want to add non-opensource software to the tree ? Here is what I would say:ravelo wrote:Theses problem is not existant for open source applications, we are allowed to modify and repackage them.
For shareware and ad-supported software - NO. And freeware yes, but only if there is no opensource alternative and if the author agrees with it. In this case we can also repackage it.
If our package becomes more important one day we might stop adding freeware to the tree, in order to convince some authors to make their software OSS. :Wink:
We can convert them to our script lang (or installers), when we have decided what that would be.Maybe my batch script can help in some way?
Here is another thing about the installer, how do they communicate with the dll ? How do they report errors ? Do they show their own status bar ? I would prefer to have a status bar for everything. This is a argument for a script lang.: It integrads better into the interface.
But they need to send them to us and we will upload it.packages will maintained by users...not only by applications writer, so who wants can do a package of an app
PS: Don't forget to extent the wiki page. There could be a sections for command line optionsand for API calls the dll provides. Also a description of the GUI would be nice.
Last edited by Dr. Fred on Sun Jan 02, 2005 8:01 pm, edited 1 time in total.
Where do you want ReactOS to go today ?
This sounds reasonable. Would make things a lot easier in the beginning. Although we cannot include applications like total commander 5.51 then.Do we want to add non-opensource software to the tree ? (...) NO. And freeware yes
I found a program that does sort of second stage installation of applications (the only one i could find for windows):
http://www.kalytta.com/wihu.php
Lots of discussion about silent installation of applications is going on here:
http://www.msfn.org/
Well I agree with the point to not include shareware and adware, but I'm all against excluding freeware. For example I have made software in a language which have no free compiler, how would that be handled?Dr. Fred wrote:Do we want to add non-opensource software to the tree ? Here is what I would say:
For shareware and ad-supported software - NO. And freeware yes, but only if there is no opensource alternative and if the author agrees with it. In this case we can also repackage it.
If our package becomes more important one day we might stop adding freeware to the tree, in order to convince some authors to make their software OSS.
And most windows users (and possible future reactos users) would want to have binaries probably.
I extend RosWikis Packet Manager page with a GUI and a command line section.Dr. Fred wrote:Don't forget to extent the wiki page. There could be a sections for command line optionsand for API calls the dll provides. Also a description of the GUI would be nice.
What about traffic lights or checks for different license types.
Green light/check for open source apps, orange for freeware and red for shareware.
On my homepage I have such a system:
http://reactosde.re.funpic.de/catdistri ... rt=appname
The scripts for the installs should either be based on VBscript/basic, or xml. Windows developers should not be made to have to learn yet another new language. There are already too many people have to know. For the best support it should be kept to the classic and simple. VBscript support will be required, and it allows for more developers for ReactOS and thus more programs and support. You do not need the extra functions and pain of things like python, perl or some other less used language.
Who is online
Users browsing this forum: Ahrefs [Bot], Bing [Bot] and 35 guests