I'm fighting with OSX's packageMaker as it doesn't allow me to create a '.pkg'. Instead it's forcing me to make a '.pkg.mpkg'.
This seems like a stupid question I should be able to respond with a couple of google searches, but I'm not being able to find much info about this.
Could anyone explain the main differences between them and if you know the restriction for which you have to use one or the other?
To the best of my knowledge, .pkg files are simple, straightforward Installer packages. However, .mpkg files are very customizable, and can link to multiple .pkg files which the end user can turn on and off in the Installer.
I think the .pkg.mpkg double-extension you're seeing is just a text appending issue. Packages are either .pkg or .mpkg, not a combination of the two.
I believe Collin Allen is correct -- the main difference is that the metapackage can reference other packages. But as to your PackageMaker problem, have you tried Iceberg? It's an alternative (free) that we have had generally better luck with: fewer bugs, easier to understand and use, greater freedom, etc.
I don't have a good answer, but PackageManager automagically switched from .pkg to .mpkg once I tried to modify the text that the user sees. Both included sub installers (.pkg) prepared by vendors.
Related
My company does Linux embedded systems using Freescale PowerPC processors.
Some years back I wrote an internal HowTo on how to use Dan Kegel's crosstool to set up a cross compiler environment for our product. I hadn't touched it since then but I recently tried it and found it doesn't work. The scripts look for files on redhat.com's ftp server that are currently not there.
The latest cross tool script is the one I am using, version 0.43.
So before I roll up my sleeves and see if I can fix it myself, I am wondering if someone has already done this. Does anyone here know Kegel well enough to contact him and ask if he is planning to do an update? (My guess is not. He works at Google now.)
Alternatively, is there a better GNU cross tool builder than Kegel's cross tool? It might be easier to switch over than to update the old one.
As it turns out Mr. Kegel was kind enough to respond to my e-mail. It turns out his original scripts have been picked up by an open-source group that calls it crosstool-ng. They did an amazing amount of work on this and the tool now uses a curses-based menu system to select the options for the cross development to generate.
You can search for file names directly in Google (try '<filename> site:ftp.redhat.com' or something similar), and often results will yield revised links to the files. If that is the problem, it should just be a case of cut and paste. Alternately, I would recommend downloading the files locally, modifying the script to see them there and then bundling them with the script.
Kegel left Google for a startup. His resume is at http://www.kegel.com/resume.html . Have you tried emailing him? He might just respond.
Has anyone got any experience in doing this?
Specifically, I'd like to find out if any registry keys are being written and what files are going where when I run an MSI.
I was thinking of using ProcMon to see what the msiexec process is doing while I run through it but just thought I'd run it by here to see if anyone has a better method.
Bit rusty, but here's a few (maybe) helpful pointers.
There is a tool called Orca that you can use to edit MSI files.
There was also Wise for Windows, which is now called something else, and I'm not sure what you'll be able to do with the trial, it definitely had the ability to edit MSI files.
I was going to suggest FileMon and RegMon on their own, but I just saw they've actually been merged into ProcMon, shows how behind the times I am :)
Ideally, the setup author used only the Registry and COM tables so it's very easy to just look with Orca what's being done. However many setup authors produce less then idea installs. In those cases I use InstallWatch to snapshot the registry before and after to generate a difference.
InstallWatch Pro
You'll see other line noise from processes running on the machine but you learn to filter those with experience. ( E.g. the install didn't change the crypto seed or the MRU's and ShellBags )
Microsoft's "Windows Installer CleanUp Utility" could be used to help fix broken installations of MSI-installer based products. When the installer failed in some strange way and left corrupt data behind, so bad that even Add/Remove Programs couldn't help, you could often fix things by running this utility and then running the application's installer again.
I just discovered that Microsoft announced a couple weeks ago that they were discontinuing this utility. They didn't merely say "we're not supporting it anymore"; they seemingly removed it from their site entirely.
I have to support a Windows program for a whole bunch of users. Given the number of users, every so often something will go wrong, and this program has been invaluable for me, as a last-ditch line of defense.
I know I could point customers to some third party site that has a cached copy of it, but this seems dangerous (malware potential and such).
So, are there any replacement products? Or, if not, how can I myself do whatever it is that this program did?
To be clear, I'm not asking for help like "how do I programatically modify the registry". I can do that fine. But I need to know what in the registry needs to be modified.
Thanks in advance.
Windows Installer CleanUp utility was never intended to be used in the wild. It was only meant to be used by software developers. If you occasionally have end users needing to use WCU you have some serious installer quality issues that should be addressed.
WCU only removes the Windows Instaleller meta data and doesn't actually uninstall any software. This leaves the machine in a very dirty state. These days with test labs becoming virtualized there's no reason to have this tool anymore. You just roll back to a prior snapshot and keep on working.
I've seen all kinds of online forums full of users who think they know what they are doing ( and don't ) suggest using WCU to solve various problems so in the end Microsoft decided to try to get the horse back in the barn.
I have old copies of WCU archived in my CM system so if you'd like me to generate checksums to help you determine if you are getting a good copy just let me know.
The cleanup utility was a wrapper around the command line utility msizap.exe, described here:
http://msdn.microsoft.com/en-us/library/aa370523%28VS.85%29.aspx#1
There's lots of questions about installers but I haven't seen one about whether or not to actually use one in the first place.
What is the logic behind using them in the first place? Can't the user just extract it somewhere? But I guess it depends on the target user.
And on the subject of the actual setup: Can't that be done on the first startup?
It very much depends on your target audience, and what your installer needs to accomplish.
If your audience is technically savvy, and the installer just has to extract some files, and create shortcuts, I probably wouldn't bother.
If you need to modify system variables, register services, etc, definitely create an installer to make life easier for your users - regardless of how technically savvy they are.
You can always offer the option of installer / no installer, and let your users decide what they want. The number of downloads and resulting support requests will tell you whether you should utilize one or not.
And on the subject of the actual setup: Can't that be done on the first startup?
uTorrent used to do this (I'm not sure if it still does... I update automatically) and I found it a little confusing at first, since I'm used to installers. For users that are possibly clueless though, it's perfect.
For more complicated applications that have multiple files installed to several locations, I think it's better to have an installer. For a series of products we produce where I work, we have several 'flavours' of installer for each product: auto-update installers can be smaller as we know the user already has prerequisites. New users, though, get a larger installer.
I can't see any reason not to use an installer. When you use something like Inno Setup, creating the installer is no more difficult than creating a zip file, and you don';t have to explain to the user how to install.
Having an installer will help your users a lot.
The application will be installed at the right place
The user won't have to set links in program files himself, or copy the extracting content you suggest in a directory
Your application will looks more professionnal
Moreover:
The user will know that using the uninstall system of windows will safely remove your application without affecting the system
You need something which can set up the registry and install prerequisites before starting the app, that's why you need an installer :)
Including a well designed installer can also add value over the lifetime of the application by enabling the application to be updated and enabling the application to be uninstalled cleanly. Eventually the user will want to uninstall the application, and the ideal is to leave their computer in the same state as prior to installation.
Last year, in 2009 GSoC, I participated with an organization called Winlibre. The basic idea is having a project similar to Aptitude (or Apt-get) and a GUI like Synaptic but for Windows and just to hold (initially), only open source software. The project was just ok, we finished what we considered was a good starting point but unfortunately, due to different occupations of the developers, the project has been idle almost since GSoC finished. Now, I have some energy, time and interest to try to continue this development. The project was divided in 3 parts: A repository server (which i worked on, and which was going to store and serve packages and files), a package creator for developers, and the main app, which is apt-get and its GUI.
I have been thinking about the project, and the first question that came to my mind is.. actually is this project useful for developers and Windows users? Keep in mind that the idea is to solve dependencies problems, and install packages "cleanly". I'm not a Windows developer and just a casual user, so i really don't have a lot of experience on how things are handled there, but as far as I have seen, all installers handle those dependencies. Will windows developers be willing to switch from installers to a packages way of handling installations of Open source Software? Or it's just ok to create packages for already existing installers?
The packages concept is basically the same as .deb or .rpm files.
I still have some other questions, but basically i would like to make sure that it's useful in someway to users and Windows developers, and if developers would find this project interesting. If you have any questions, feedback, suggestions or criticisms, please don't hesitate posting them.
Thanks!!
be sure to research previous efforts on this. Google turns up several similar/relevant efforts.
http://en.wikipedia.org/wiki/Package_management_system#Microsoft_Windows
http://windows-get.sourceforge.net
http://pina.plasmite.com
IIRC there was an rpm for windows at some point
Also I think there was some guy (who used to work at MS) in the news recently that basically is starting up a very similar project. I can't find a link to this now.
But anyway, yeah, it would be awesome if there was such a standard tool and repository.
I can only speak for myself, but obviously I could definitely make use of such a tool as I found your post through googling! ;)
My two use cases for this tool would the following ones:
1. I generally avoid to re-install my system as long as possible (in fact I manage to do so only for switching to a reasonable (not each an every) new version of Windows every few years or to setup new computers). But still I'd like my software to be up-to-date. Neither do I want to have to go to all the web pages and check manually if there are compatibility issues with the new version of Doxygen, Graphviz and the latest version of MikTeX for example, nor do I want to have to navigate to the download pages and run the setups all by myself. I just want to schedule ONE SINGLE (!) tool, which checks whether there are new updates or not and updates those applications which are not in conflict with any other application version.
If it unavoidably happens to me that I have to re-install my system, I don't want to get the new setups neither (and check compatibility). I even don't want to wait for one setup to finish in order to start the next one, I just want to check the tools I need, or even better, I want to simply load my "WinApt XML" batch installation file, which gets the installers and handles the setups sequentially all by itself.
I don't know enough about the architecture of .deb or .rpm but IMHO the most reasonable would be to maintain a DB with only the names, versions, dependencies and the location of the different versions' download locations. I mean, most of the tools available for Windows provide .msi packages anyways, which (I guess) is the application itself and some custom installation properties (really not sure how scripting is handled, but I know that creating a MSI in Visual Studio has very limited abilities to create custom installation steps and I can only imagine this is due to limitations of MSI protocol).
I guess a GUI will be mandatory for Windows users ;) but I personally would prefer the additional ability to handle the setups with the console.
Well, I like the idea and would love to hear from that (or such a) tool in the future.
Cheers
Check out NSIS. It's an open source MSI creator. You might be able to use it as part of your package creation software.
http://nsis.sourceforge.net/Main_Page
For the ALT-.Net tool/lib stack there have been some affords in this direction: Horn Get
However, the usability in a real world project has been subject in this SO question.