Package Manager

[Dr. Fred]

in my country are 22.00 ^^
i live in italy

Yes. I'm living in same time zone as you.

you can try to read it in english using google ^^

Didn't work.

In my mind the main question still is if we are allowed to use python. So I posted the question to the mailing list.

EDIT: Here is my post.

[frik85]

In my mind the main question still is if we are allowed to use python. So I posted the question to the mailing list.

I like the xml idea. Maybe XML + simple script language (like basic/vbscript) or batch file support.

[NetSlayer]

A package manager would be so great...

I had the same idea some weeks ago but I thought the ReactOS developers wouldn't like it because "we don't want to be Linux". But package managers are IMHO the best pieces of software in Linux distros

I could help to program a graphical package manager in C.

[daniele_dll]

A package manager would be so great...

I had the same idea some weeks ago but I thought the ReactOS developers wouldn't like it because "we don't want to be Linux". But package managers are IMHO the best pieces of software in Linux distros

I could help to program a graphical package manager in C.

we don't want to reproduce "linux" with a package manager, but want to give the possibility to set up a system fastly without the necessity to download from severals serevrs packages to install manually...instead having a reopsitory would be great...who wants can use binary packages or sources and this can help seriously users

and, hovewer, something like this can be used on windows too

---

I like the xml idea. Maybe XML + simple script language (like basic/vbscript) or batch file support.

i think that isin't a good idea to used a basic like syntax because it is very limited. And, however, if scripting support will added, is necessary to use something not to hard to add to the package manager (python support is very simply to add)

[frik85]

A package manager would be so great...

I had the same idea some weeks ago but I thought the ReactOS developers wouldn't like it because "we don't want to be Linux". But package managers are IMHO the best pieces of software in Linux distros

I could help to program a graphical package manager in C.

I also could help with XML experience and writing a script engine (new script language or basic/vbscript).

[daniele_dll]

A package manager would be so great...

I had the same idea some weeks ago but I thought the ReactOS developers wouldn't like it because "we don't want to be Linux". But package managers are IMHO the best pieces of software in Linux distros

I could help to program a graphical package manager in C.

I also could help with XML experience and writing a script engine (new script language or basic/vbscript).

i continue to think that instead to do newer things we should use existent things because they are very very flexible and powerful...

there is a big work to organize well repository and the dependence system :\ the script engine is a secondary thing...

[NetSlayer]

we don't want to reproduce "linux" with a package manager, but want to give the possibility to set up a system fastly without the necessity to download from severals serevrs packages to install manually...instead having a reopsitory would be great...who wants can use binary packages or sources and this can help seriously users

You're describing the use of a package manager. Great, but I know what you're talking about. Package managers have nothing to do with Linux, but as I said most distro creators use them.

and, hovewer, something like this can be used on windows too

I know it from Debian. btw: I never said it couldn't be used in a Windows environment (dude, I want to help, I know it works!).

i continue to think that instead to do newer things we should use existent things because they are very very flexible and powerful...

Uhm, yes - but a package manager doesn't need a _real_ script language with arrays and stuff. It only has to offer simple commands like "copy", "run" (if the user allows it), delete (but better not allowed when installing), addtoreg, delfromreg (to uninstall, like delete).

After execution of the script file, the package manager could create an "uninstall" script itself, using the "copy" and "addtoreg" commands and reverting them to "delete" and "delfromreg".

Just a suggestion.

[Denzil]

i continue to think that instead to do newer things we should use existent things because they are very very flexible and powerful...

I agree with that. If we will use XML based package manager we can just port with a little changes the one that is used in gentoo linux.

[daniele_dll]

lol i love gentoo :DDD

but i don't belive that emerge will be what we are searching...because is necessary a more windows way to do things...it needs to work using windows standard

for this, in previous posts i've mentioned MSI, but i don't know well how it works

however the idea to use an installer is more interesting because all can be managed using windows registry and xml can be used only to store (on servers) a tree of packages

simply, fast and efficent

if you need to compile...there aren't problem...using an installer engine the package manager project can supply 2 templates...one used for binaries and one used for sources, and in this template can be "prepare" some code that will be only to be modified

there are packages like nullsoft installer and innosetup that are very interesting

- User starts PM (Package Manager)
- PM downloads the last xml tree
- User selects a package to install
- PM get mirror list and try to download it
- After download, PM will simply start installer
- After install PM will reload installed packages from registry

this can be a very simply and flexible way to do all...because using standard templates as base all will work with package manager, using softwares like innosetup or nullsoft installer (NSI) you can code all that you will need...and personalize your setup with shots and other, and you can use these packages without package manager

however there are many ways to do a work like this

[Denzil]

I think that we will need more than one XML tree. One for installation from internet, another one for install from ReactOS CD (someday in future), one for install from local server. Or maybe it will be better to have separate XML tree for every application because maintaining of one big XML file will be difficult. Also with one XML file for one application we can just download only changed files or branch of applications (user is interested only in office applications so we will download only branch of XMLs with games ) which will be faster and we can download the right XML file for different languages.
I guess we will also need to hash every official package after download for safety reasons.
I guess we can use wget for downloading packages (wget is not working yet but it is one of goals for 0.3)

[frik85]

lthere are packages like nullsoft installer and innosetup that are very interesting ...

... using softwares like innosetup or nullsoft installer (NSI) you can code all that you will need...and personalize your setup with shots and other, and you can use these packages without package manager

Inno Setup is a Delphi 3 app! The Ros Packet Manager should be written in C (or C++).

[daniele_dll]

lthere are packages like nullsoft installer and innosetup that are very interesting ...

... using softwares like innosetup or nullsoft installer (NSI) you can code all that you will need...and personalize your setup with shots and other, and you can use these packages without package manager

Inno Setup is a Delphi 3 app! The Ros Packet Manager should be written in C (or C++).

inno setup is an installer...packet manager...is a packet manager ^^

------

denzil have more xml is a bad idea because will be a problem mantain all xml tree updates...but have an xml tree and some "profiles" will be more useful in fact...if you want to set up a web server...mail server...and ftp server you can select these 3 profiles and all will be done automatically

mmm xml will be little...and compressing it using bz2 it will be more little...one xml for one application can be a good idea but an xml tree will not be more useful and to download all xml files will be necessary to search into all repository tree

hash is essential :DDD
to download packages isin't necessary wget windows has many components to work with remote servers like http and ftp 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

---

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? :DDD

[NetSlayer]

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? :DDD

More bugs? What? What does a language have to do with lousy programming? You can get as many bugs in a .NET program as you can get in a C/C++ program. And if you want even more.

And what more features?

I don't think that "You have to download Mono to run the Package Manager for ReactOS" is a feature.

[daniele_dll]

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? :DDD

More bugs? What? What does a language have to do with lousy programming? You can get as many bugs in a .NET program as you can get in a C/C++ program. And if you want even more.

And what more features?

I don't think that "You have to download Mono to run the Package Manager for ReactOS" is a feature.

ehm...i've explained myself bad...
think that using C or C++ "should be" that there will be more bugs because code will be (naturally) more...is natural that if i have a milion of lines i "should" have more error that a source code of ten thousends of lines...
mono will probably included into reactos because is necessary to start dotNet apps, and however (from wikipedia)

The next release (0.2.5) will have experimental TCP/IP and is expected around the beginning of 2005.

ReactOS developers are working on improving the GUI system, adding networking, multimedia, and plug-and-play hardware support. Java and .NET support (through Mono) are also important fields that need to be worked on. Work on the DOS, OS/2 and POSIX personalities has been stopped, being deemed of minor importance.

In October 2004, the goal for version 1.0 was set to the stable implementation of a subset of Windows NT 4.0 Workstation ("ReactOS Workstation"), including TCP/IP networking, client-side and server-side support of CIFS, OpenGL, DirectX and better support for Windows device drivers.

they needs to be implemented...but however i've just asked for the possibility to use .net, not other

[frik85]

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? :DDD

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

Two complete different opinions in two days ???

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!