A Windows-Based Packaging Mechanism
FishWithAHammer writes "As part of my Google Summer of Code project, I'm working with WinLibre to develop a Debian-like software download system for free/open source software on the Windows platform. My reasoning is that open source software suffers from poor presentation. Most computer laymen, even those aware of open source software, often don't have any idea how to go about looking for it, but would use it if it were easier to access. What I have proposed is both a Debian-style packaging mechanism (capable of using Windows Installer MSIs or not, as the user wishes) and a software 'catalog' that takes the best aspects of Synaptic and Linspire's Click-N-Run system. Seamless, simple installation and removal of programs in as straightforward a way as apt-get (there will be a command-line tool as well). I'm posting to Slashdot to get the ideas of you lot who, while you may not be the target audience, can certainly provide insights that can be of value." Read on for more of this reader's ideas and questions.
There are areas that I'm personally not familiar with, and while I have done some research I would like the opinions of Slashdotters on some others. While at first I intend to set it up so that WinLibre (and I) run only one repository, I am curious as to how this sort of tool could be most useful to network administrators. Customizable repositories will be available; the code will be under the GPL, after all, so it'd be a little hard for them not to be available.
I'm also interested in the ideas of those who might be in a position to roll together packages. I intend to package a number of open-source language interpreters with the core software to allow special pre- and post-install scripts, as well as removal scripts. C#Script, Perl, and Python are definites, as is a Cygwin sh interpreter. We will have some program requirements — chief among them that no registry changes may be made by the program — but some of them, I fear, will require some flexibility; some programs really do require a way to edit the registry, for example, and I am considering offering some sort of tracked way to make registry changes so they can be rolled back on uninstallation of the program.
I'd love to hear what Slashdotters think of this. Think of it as a wishlist, but you don't get any damn ponies.
Ed Ropple (FishWithAHammer)"
There are areas that I'm personally not familiar with, and while I have done some research I would like the opinions of Slashdotters on some others. While at first I intend to set it up so that WinLibre (and I) run only one repository, I am curious as to how this sort of tool could be most useful to network administrators. Customizable repositories will be available; the code will be under the GPL, after all, so it'd be a little hard for them not to be available.
I'm also interested in the ideas of those who might be in a position to roll together packages. I intend to package a number of open-source language interpreters with the core software to allow special pre- and post-install scripts, as well as removal scripts. C#Script, Perl, and Python are definites, as is a Cygwin sh interpreter. We will have some program requirements — chief among them that no registry changes may be made by the program — but some of them, I fear, will require some flexibility; some programs really do require a way to edit the registry, for example, and I am considering offering some sort of tracked way to make registry changes so they can be rolled back on uninstallation of the program.
I'd love to hear what Slashdotters think of this. Think of it as a wishlist, but you don't get any damn ponies.
Ed Ropple (FishWithAHammer)"
That's great of course, but it's the community and a selection of packages with mutually consistent packaging metadata which make systems like Debian and their derivatives so popular. The packaging system itself is an enabling technology.
interesting but for it to be popular on window IT HAS TO HAVE a user friendly interface not just a command line tool (btw look into new powershell for windows ;) )
I would say the big thing that I would look for in such a product would be a consistent (or even better, non-existent) use/removal of registry entries. I have dealt with so many so-called "professionally" done software pieces that upon uninstallation would leave several dozen registry entries. This seems terribly unnecessary, and if the so-called apt-get method could circumvent the registry (much like the run from USB flash drive programs) altogether, or at least make it a sure-fire thing to remove, instead of wipe-and-pray.
Good on you for trying to better the system man, I wish you the best of luck!
Uhm, let's compare signed repositories with grabbing those programs you need from websites, and quite a few of them use random services like download.com.
Quite a step forward in my book.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
For user-specified (or multiple fallback) repositories, you need nothing more complex than reading your base path(s) from a config file. Prepend that address to every file you download, and it will all go well.
For the bigger project, basically you just need a set of per-package install/uninstall scripts that check for dependancies (or no-longer-needed dependancies on uninstall), do their thing, and write themselves to a standardized catalog of installed software. Whether or not you can adapt Windows' list of such software, and the MSI interface in general, to your needs, I can't say offhand. I would think you can at least list the package therein, but I don't think that handles dependancy information quite as elegantly as you would want.
I see the biggest problem you'll have as coming from the poor regression testing done for Windows ports of FOSS - You may well need multiple (version-specific) instances of some dependancies installed at the same time, for different packages that use "working until version 2.8.10.4" features (or more of a nightmare, "working until KB935356").
Overall, I wish you luck with this. I think the Windows world has needed something like apt-get (with a mind-numbingly simple GUI) for a loooooong time.
There is a mechanism for doing this kind of thing already in Windows, via Add/Remove programs and Group Policy. Surely it would be a good idea to try and re-use this rather than re-inventing the wheel.
I hope you're planning on making it interoperate with the cygwin packaging system. Cygwin's a great piece of software which is, IMO, let down by its obscure and difficult-to-use setup program. A new, friendlier way of installing and updating cygwin components would be a great asset. And if it worked with other OSS stuff as well, that would be a huge asset.
.exe that doesn't require your system, but which can interoperate with your system easily -- perhaps by having a version of your system that can wrap up a package with a copy of the relevant parts of itself in a .exe file.
One thing I would suggest is that you make it easy for somebody to package a standalone
It is not only the programmers' fault, though. Far too few users bother to suggest interface simplification,or even know how to advocate it. Merely complaining will not work - developers need to be shown that it can be done, and how, by means of mock-ups or illustrations. A few innovative user interface interested users could do wonders for many projects simply by drawing new user interfaces and submitting them to various free software projects, asking if they are interested in going a few rounds of design iterations with them. Often an outside eye, and interest in doing some adapting from both sides, is all that is needed.
I want to highlight some differences between dpkg/yum/whatever to the Windows platform. You may like to carry some features of *nix, but doing so will require you to re-educate the users, and thus your package management will not get adopted.
1. Windows users expect the Next->Next->Next->Finish paradigm. *nix users expect the "silence is golden" rule.
2. *nix advocates dynamic linking. Windows has DLL-hell. This is because the distribution can suggest the library versions and the user can choose a difference library version by recompiling dependants. This is not possible in binary only distribution.
3. Windows software comes from multiple sources. You must allow others to host their packages and only link to other places. Don't try to make one large repository. You can however, maintain one large catalog and allow others to edit their entries in your catalog.
4. If users will be able to add entries to your catalog, they will add bogus software. A later version will have to allow the users to rate the packages. Use the users to make your content, you only supply the means.
5. Interaction with MSI is non-trivial. Start with a prototype of your system that use zipped packages (optionally with a manifest file). Once all the pieces is in place, start adding support in msi packages.
It's a stealth feature. Get people installing applications that way, because then the Linux desktop will be more familiar.
Something really is needed. I keep coming across people who really need no more than Wordpad who are buying Office because they think they have to. I recently came across a guy who has bought Office 2007 and writes nothing but letters and the odd email. He thought that somehow saving his letter to Auntie Flo in Office 2007 format (docx) was "better" than saving it in Office 2000 .doc, right up to the point she couldn't open it as an email attachment and he had to "downgrade" his document. Microsoft is exploiting numskulls like that. (I'm only jealous of course - I'd love a list of 100 or so gullible people with money but, as I'm not a corporation with deep pockets, I might get into trouble.)
These people don't know OOo exists, and even if they did would never be able to find it. But a simple little packager that has a "Top picks" with something like "Open Office 2 - for all your home office needs" and a "click here to install" button - well, at least we'd be trying.
Pining for the fjords
This is one of the areas where Free Software is far, far ahead of what Windows currently has.
Right up until the software you want isn't in the repo, or is broken. Then it falls way, way behind.
There's also the "what the hell is it called" issue, but that's become less significant in the last year or two, although that benefit is largely restricted to Ubuntu and its derivatives.
This could also improve the upgrade process which would help security a lot. E.g. how man people do manually upgrade all their manually installed applications? If you can just type "apt-get upgrade" people are much more likely to update and get security updates.
Do or do not, there is no try.
I'm posting anonymously to protect the guilty.
I worked at a company that needed to be able to manage software installs. We tracked them, created scripts to install and uninstall by calling MSI or the uninstaller respectively, and repackaged them when we had to.
In order to repackage, we had to provide a log of changes to the system from the installation of the package. We used an embedded sqlite database per package to dump before and after states of the filesystem and registry, environment variables, etc.. Then we diffed the two to get the install contents based on a manual installation. Special attention has to be paid to special directories (e.g. C:\Documents and Settings\myuser must be converted, "Program Files" as well, WINNT must be specialised, temp directories shouldn't be tracked, start menu items need to be logged...). In addition, you need to be able to read shortcut files and .pif files (DOS shortcuts) to recreate them. For MSI, you can read package contents (though it's a real bitch to actually decipher it), but change tracking was the only reliable way to get changes from ALL types of packages. Don't forget to track changes of the list of services as well. In the registry, remember that we can stock binary data... Etc. etc...
Your complaint boils down to "some people make bad packages", which occurs on Linux as well, and is just the nature of software to be imperfect. I cannot count the number of bugs or non-working setups I've tracked down to bad packages, and even better, in the Linux world fixing such a bug once doesn't make it go away - it'll be repeated in 3 months time by a different distribution.
That would be nice, yes.
Installing apps on Windows is good as it is. Dont kid yourselves - package management is one of the worst aspects of the Linux OS. People already know how to look for software: You google for it, then look for a download link on the webpage you find. Package managers are almost worthless when you try looking for software to install. The search is restrictive and the descriptions minimal. Applications get lost among the countless number of small useless apps and cryptically named support files. Unless you know exactly what you are looking for, the chances of finding anything among the huge number of packages is almost nil. And don't forget most users don't even know what packages are! And why should they? All they care about is applications. Nobody wants to know what shared libraries they need or can install. And with today's hard drive sizes, there's really no point in sharing resources between applications. that just makes for more complications such as dependency conflicts.
In reality, it tends to work the other way around. Take the Amiga emulator, UAE, for instance. I think, among other meanings, the U once stood for Unix. Yet, most of the best features are in the Windows version now, and they're developed in a non-cross-platform manner, by people who don't care about OpenGL's standardisation over DirectX, etc. Same with other emulators, and probably lots of other tools.
Unfortunately, Free Software is a victim of its own generosity, when parts of it are ported to windows. Especially given that the initial ports tend to be half-hearted, and half-working compared to the Unix versions, so that people think Free Software sucks, until it's had a while to become windows-ized through its that community.
STILL... it seems obvious to me that something like a usuable, popular, apt for windows could literally beat microsoft's monopoly. When you can browse to the office section of your package manager, and you're immediately presented with a choice (Install OpenOffice now, and lots of extra, compatible software) or run install the wrapper package for Microsoft Office, after buying the CD, proving you didn't steal it with a 98-digit code, etc.)... well, it would really level the playing field.
I actually thought this was the point of Google Pack -- to beat microsoft by taking over and opening up the distribution channel. It's a shame (no, literally, a SHAME) that they didn't do a better job on that, by making apt for windows then. I'd be glad to see a real APT for windows. Unfortunately, I'm not sure it's possible, without the mass of a debian-like project behind it, a very easy and presentable UI, and open, usable APIs that encourage developers to use it. Hint: it has to work as well as apt, but not be half as hard to make packages for. Good luck, I say.
I'd argue that apt-get is less intuitive and harder to admin. Few Windows users are going to want it. Good luck finding that out the hard way.
These posts express my own personal views, not those of my employer
If it uses MSIs, this might push Mozilla to start building MSIs of their software - something corporate users have been demanding since forever.
Linux will gain market share over Windows by being better than Windows. My experience with open source came through open source applications on Windows. I use those applications because they are superior, not because they are free. I think those apps will work even better if I replace Windows with Linux. So think of open source apps on Windows as a gateway drug to Linux (or *BSD).