Browsing this Thread:
1 Anonymous Users
|
Re: Installer
|
||||
|---|---|---|---|---|
|
Home away from home
 
|
Quote:
Okay, I am seeing what you mean. You just didn't state it too well before.  Now is the matter of defining how the installer script is written so as to be able to parse it for the info the package manager needs. Oh, I also think the PM should just save the installer scripts to keep track of what is installed and its version. It could either keep them in a local directory, or even compress them in a file if you wanted to save space. I really don't see the need to compress the scripts as the size of the average installer script compared with harddrive capacities makes that silly. Also, compressing the scripts in a file makes it more likely to be lost in case of corruption - one byte gets whacked and your entire arc is gone (unless you compress with redundancy).
Posted on: 2004/10/16 22:41
|
|||
|
||||
|
Re: Installer
|
||||
|---|---|---|---|---|
|
Home away from home
|
Quote:
its not about why we cant have, please try to understand that, its just some packages / apps need that bit extra. Your "simple" package example could easily be catered for by what i am suggesting. How complex the install is isnt what we are discussing - thats for the package writer to deal with. What we ARE discussing is why use dos scripts in favour of installer - when Amiga apps already use installer (i guess you could call it the standard ;P), and we HAVE installer already in AROS. If it was such a simple decision - dont you think people wouldnt have bothered using installer before and just done dos scripts .. Quote:
surely its not that hard for you to imagine an app that requirs some kind of user intervention, or installs itself differently depending on what is currently on a users system (or a plethora of other variables). You cant think of a single application that doesnt have extra bits you dont want to install? If you really are struggling i will put a list together but thats not what i was wanting to do, more to discuss whats needing done =/ Quote:
As i said before - its no as easy as you are making out .. you are only talking about 1 scenario - but there is a bigger picture imo.
Posted on: 2004/10/16 22:40
|
|||
|
||||
|
Re: Installer
|
||||
|---|---|---|---|---|
|
Home away from home
|
Quote:
Programs which have libraries or scripts that go in s: or other such thingys wouldn't work too well unless they were changed to refer to everything in its drawer. Then you wind up duplicating common resources because everyone has them in their drawer. Quote: we still can handle dependencies and versions using regular dos commands. we only need to standardize how package should be! (my 2 cents)...otoh if we do a make install will break any standard! =o\ Yes, DOS scripts can get user input, but it's very rudimentary (print a line and look for a yes/no kinda answer). That's why Kalamatee wants the installer - some proggies have much more complex requirements. Not many for certain, but a DOS script would be rather convoluted for those packages.
Posted on: 2004/10/16 22:32
|
|||
|
||||
|
Re: Installer
|
||||
|---|---|---|---|---|
|
Home away from home
|
Quote:
no! lol A> yes i want to use installer because we have it already, and installing a package is still installing. B> NO! theres no reason the info your suggesting is in a metafile cant be in the very same install script (which is what i mean). C> NO! Installer creates an uninstall script based on whats actually happened for that install. Quote:
90% seems a grand exageration to me The least complex scenario i can see is a system file update that requires no input. its install script could be written to only display the "copying files" or updateing information. Next comes the more common scenario in my opinion - those that want a user specified "install location", which is a form of input i beleive. They would have a slightly more complex install script but still nothing particulrly special. Finally you have either of the above that need far more user intervention. Since they could be doing anything they _might_ need a more complex install script. but then wouldnt an app using dos scripts also need a complex script to achieve the same? Quote:
See my above comment ... Quote:
I think your starting to see the picture i have in my head. The "install" "options" could also have their own variables names - for use in the automation process thats also been mentioned ... so long as we have a clearly defined way of doing it i dont see the problem.
Posted on: 2004/10/16 22:28
|
|||
|
||||
|
Anonymous
|
Re: Installer
|
|||
|---|---|---|---|---|
|
why we cant have only a package that can be unpack for a folder that the path will be "registred" and all the app be contained into it folder?
(what example could we have that doesnt fit in this scenario?) we still can handle dependencies and versions using regular dos commands. we only need to standardize how package should be! (my 2 cents)...otoh if we do a make install will break any standard! =o\ user inputs can also be handled by normal dos script, isnt it? best regards, |
||||
|
||||
|
Re: Installer
|
||||
|---|---|---|---|---|
|
Home away from home
|
Hmm, I think we differ as such:
You want to use the Installer, I want to use DOS scripts. You want a metafile, I want to derive it from the DOS scripts. You want the PM to derive the uninstall procedure, I want a DOS script for uninstall. I think that about sums it up. You want the installer because some installs can be complicated and may need user input. I want the DOS scripts because >90% of installs just copy files. I suppose I can go along with using the installer. As you said, making an installer script that just copies files isn't that complicated. More than a DOS script, but nothing anyone can't handle. I suppose I could go along with a metafile of some sort. However, now you run into a case where someone may update the installer script and forget to update the metafile. I still think it's better to derive the metadata from the install script. Scanning a installer script for the needed data is about as easy as scanning a DOS script. You could even require that certain variable names be used in the installer script to make it easier. That way, there is only one script that does everything - install, uninstall (most installer scripts also have uninstall capabilities), and provide the PM with the metadata.
Posted on: 2004/10/16 21:35
|
|||
|
||||
|
Re: Installer
|
||||
|---|---|---|---|---|
|
Home away from home
|
one other thing - it would be trivial for installer to create an "install specific" uninstall script, but i doubt writing a dos script to cover all options for an "install" would be quite so easy. and im not talking about for a simple "copy the files" type app but one which may for instance only copy files depending on env settings or other external factors.
Posted on: 2004/10/16 3:59
|
|||
|
||||
|
Re: Installer
|
||||
|---|---|---|---|---|
|
Home away from home
|
Quote:
This is where i mostly disgree. A simple installer script is easy to write. So is a simple DOS script. A complex script of either becomes more tricky - but your implying installer scripts require more work than would writing DOS scripts which is nonsense. Quote:
Theres many Apps that i wanted to install certain parts in certain locations not all together, or even (can you imagine) not install every printer driver, graphics driver or other component i didnt actually need (replace with components from app of your choice) - novice doesnt accomplish this. Just because your happy with that (what would be a novice install) doesnt mean everyone else is or should be and thats what im trying to get accross. one point i would mention though is that most "installation" require at least a source path - writing an install script to retrieve it and copy the files isnt brain surgery. Quote:
Where exactly are you getting that from? where did i propose anything other than using installer that differed to a great extent. How would putting the uninstaller etc into package manager make it less complex? Or how even would making it do the unpacking make it so? please dont make out i said something i havent - what your proposing is a far more complex "package manager" than what i proposed. Quote:
and whats complicated about .. for handling of downloaded/on media packages, package manager calls installer with differing options depending on what it wants to do -: installer --dependancies package.name --> cause the dependancie part of the install script to be called. this could check for whatever the script writer wanted within limits of Installers abilities. If other packages are required, package manager could be informed through some mechanism as to whats needed. If some other process is needed to be performed - that can be scripted in the install script, again within the limits of installer. installer --info package.name --> retrieve the packages details from the install script. Basic package info such as name, version, what package(s) - if any - it replaces, etc. installer --install package.name --> cause the selected package to attempt installation/update. if the ".aut" file exists use the settings from it for the installation options. During installation an uninstall script is generated specific to the installation that has taken place. since the package files are essentially some kind of archive format - installer only really needs "expanded" to support extracting the format to the previously mentioned temporary repository from where it can call/process the install script. Package manager itself only needs to know how to maintain a list of packages, and retrieve new packages. at the most it must process the output of installer. Quote:
Likewise =) but your proposal just feels like it neglects what other people might/will need just to be simple - which is a bad thing imo. As i mentioned before some of the functionality (uninstaller etc) ive started as part of my InstallAros project which isnt anything to do with "installer" at the moment, but at some point i would like to try and use the engine that resides in it with the aros installer propper - so that it provides the gui to the installer script engine (ive discussed this with xhenning on the irc channel a few times - hes the guy behind our propper installer) and the install process for aros itself will then just become an installer script. Another part of the process is seperating out the common IO functions to be performed by a seperate task.... but thats a whole different ball game ;P Quote:
I think our goals are more similar than you might think, just certain specifics differ..
Posted on: 2004/10/16 3:53
|
|||
|
||||
|
Re: Installer
|
||||
|---|---|---|---|---|
|
Home away from home
|
DOS scripts are far easier to write than installer scripts. I've written both and I much prefer DOS to installer. Installer is only good when you need user input.
When was the last time you did an "advanced" install where you did more than simply click "okay"? Might as well have just done the "novice" install. I'm trying to simplify the package manager to make it more likely to be written quickly. Making a complex package manager means it's less likely to be out anytime soon. It'll be a mess for quite some time as all the bugs get worked out and "advanced" features noone ever use get implemented. The installer is complex enough, then you want a package manager that's even worse? Look at my proposal: version # - package manager scans "install" for "echo ""vers"" dependencies - package manager scans "install" for "IF EXISTS" actual install/update - package manager executes "install" uninstall - package manager executes "uninstall" The only part of the package manager that presents a challenge is the part that scans internet repositories (once they exist). Of course, scanning a disk based repository is child's play. Such a package manager is simple to write, easier to debug, and suitable for 99% of installations. If everyone decides on something else, that's fine with me. I'm just making a proposal of what I think is quick, easy, and suitable. I won't die if it's not accepted. We disagree on how we see AROS repositories and installations happening, but there are more people in this project than just the two of us. It may be that neither my idea nor your own will be chosen in the end. It may wind up being a combination of our ideas. The point is that we put up our ideas so that the others can make suggestions and get ideas of their own.
Posted on: 2004/10/15 18:12
|
|||
|
||||
|
Re: Installer
|
||||
|---|---|---|---|---|
|
Home away from home
|
Quote:
Your other thread implies the opposite - that there shouldnt be need for user intervention... Quote:
Umn, so why couldnt you pass the package file straight to installer no matter what the case, and if their is a fancy install script inside, it process and runs it, else it prompts for a location to install to and just unpacks it as it where. As i previosly said, the installer could easily be expanded to create an undo record that would reflect whats actually been done, not just a script that was pre written. Package manager is only for maintaining the list of packages i thought? Oh yes 1 last thing, i dont remember many apps i installed as "novice", personnaly i always choose advanced because i like control of whats happening on my system - thats part of the options that installer gives you ;)
Posted on: 2004/10/15 11:27
|
|||
|
||||
You can view topic.
You cannot start a new topic.
You cannot reply to posts.
You cannot edit your posts.
You cannot delete your posts.
You cannot add new polls.
You cannot vote in polls.
You cannot attach files to posts.
You cannot post without approval.
You cannot use topic type.
You cannot use HTML syntax.
You cannot use signature.
You cannot create PDF files.
You cannot get print page.
