Mac OS X Leopard to Include Package Manager?

Posted:
in macOS edited January 2014
Does anybody have any status on whether Mac OS X will include a package manager for keeping applications up to date and for a way to "cleanly" remove/uninstall unused apps? Of course this would include a nice GUI and support for both Aqua and X11 apps (partially fink based).



I think this is an important feature for Mac OS X Leopard and do believe users should still be able to drag an App. to the trash. Dragging and app. to the trash should however trigger the package manager and prompt the user if they'd like to perform a clean uninstall (with the option to save or delete the prefferences file).

Comments

  • Reply 1 of 18
    aquaticaquatic Posts: 5,602member
    Nice idea, I hope you wrote Apple!
  • Reply 2 of 18
    hmurchisonhmurchison Posts: 12,271member
    From the headline I thought you were making an announcement.
  • Reply 3 of 18
    Quote:

    Originally posted by hmurchison

    From the headline I thought you were making an announcement.



    I thought the same. Might I suggest the thread title be modified?
  • Reply 4 of 18
    kickahakickaha Posts: 8,760member
    Done.
  • Reply 5 of 18
    Quote:

    Originally posted by Kickaha

    Done.



    Awesome. Thanks.
  • Reply 6 of 18
    wmfwmf Posts: 1,164member
    It has been rumored for a long time that Apple might extend Software Update to allow third-party apps to use it, but so far it hasn't happened. If Apple hasn't done it by now, I get the feeling they're not going to do it.
  • Reply 7 of 18
    ngmapplengmapple Posts: 117member
    Some of the projects in the open darwin development effort would suggest a central package management feature may be in the works. Most of which suround the Fink project.
  • Reply 8 of 18
    chuckerchucker Posts: 5,089member
    Some Panther pre-release versions included DarwinPorts. It was pulled shortly before final.
  • Reply 9 of 18
    lundylundy Posts: 4,466member
    This is sorely needed, but I am not sure that it could be done in a guaranteed manner - Apple (Next) made a great organized system for keeping track of items that go with an app, but the practice by some developers has made it bad for everyone.



    It SHOULD be possible to look in the package and follow the paths put there by Xcode according to a strict convention.



    But look at Safari - plunking a "Safari" folder in the middle of ~/Library, when ~/Library/Application Support/Apple is right there in the same directory. WTF?



    And of course Microsoft just HAS to plunk folders and files all over the ~/Library, not caring if they follow the reverse-DNS convention.



    Then there are the apps like GarageBand and Timbuktu which decide to use your main /Library folder to save space or something.



    I tried to write an app once that would find all the "orphaned" prefs files (files with no remaining xxx.app file) and trash them. Due to the bizarre naming schemes used by developers for their associated files, I had to abandon that project. Look at your Preferences folder and you will see files named "My Great App Preferences", or even worse, folders named "BizarroSoftware" and nothing else, and the files inside named "Prefs", "Bookmarks", "Schemes", etc.



    All associated files and folders are SUPPOSED to be named in reverse DNS, like



    com.companyname.productname.otheridentifier.plist



    like



    com.JLSoftware.JumbleHelper.plist



    which, if followed, would allow one to search the apps for the string "com.companyname.productname" and if none were found, trash the plist.



    I'm still trying to come up with some sort of semi-heuristic way of getting rid of all these .plists that hang around after one tries out a shareware app for 5 minutes. Right now, the only way is to manually go through the Preferences folder and zap 'em. App Zapper is a pretty good heuristic model, but the problem isn't deterministic 100% given the idiotic way developers name their files and folders.
  • Reply 10 of 18
    ngmapplengmapple Posts: 117member
    Lundy, you seem to understand my concerns well. I think Mac OS X should record all changes to the file system made by an installation (so it becomes the OS's responsibility instead of getting every developer to co-operate). This way when you uninstall an app with the package manager it would clean off everything it came with, unless another app uses one of the same files.
  • Reply 11 of 18
    Quote:

    Originally posted by ngmapple

    Lundy, you seem to understand my concerns well. I think Mac OS X should record all changes to the file system made by an installation (so it becomes the OS's responsibility instead of getting every developer to co-operate). This way when you uninstall an app with the package manager it would clean off everything it came with, unless another app uses one of the same files.



    It does, actually. There's a whole list of package receipts somewhere. It's just that the OS doesn't do anything useful with them.
  • Reply 12 of 18
    ngmapplengmapple Posts: 117member
    Quote:

    Originally posted by gregmightdothat

    It does, actually. There's a whole list of package receipts somewhere. It's just that the OS doesn't do anything useful with them.



    Gregmightdothat, if you come across the details of the package receipts, let me know. I'll try and pass that along with an update to my suggestions/product feedback to Apple.
  • Reply 13 of 18
    mr. memr. me Posts: 3,219member
    Quote:

    Originally posted by gregmightdothat

    It does, actually. There's a whole list of package receipts somewhere. It's just that the OS doesn't do anything useful with them.



    Receipts are stored in /Library/Receipts and ~/Library/Receipts. MacOS X uses them to inform installers that its mother application has been installed. Receipts store the proper permission settings for their parent applications. MacOS X also uses them when it repairs permissions.
  • Reply 14 of 18
    lundylundy Posts: 4,466member
    A package receipt is an exact replica of the structure of the package whose installation it came from, except it is an empty shell.



    When you use the Mac OS InstallerMaker, you have to provide it with an actual hierarchical directory that has the same structure as the actual path that you want the items installed into.



    Go to /Library/Receipts and right-click on one of the Receipts and choose Show Package Contents. It looks exactly like a package except there are no actual files in there.



    Quote:

    Originally posted by ngmapple

    Gregmightdothat, if you come across the details of the package receipts, let me know. I'll try and pass that along with an update to my suggestions/product feedback to Apple.



  • Reply 15 of 18
    Something I forgot is that while a package receipt covers everything the package installs, it doesn't cover things an application installs?like preferences. So the method I suggested isn't quite perfect.
  • Reply 16 of 18
    daffy_duckdaffy_duck Posts: 248member
    I could be off base here but would having a package manager make developers lazy and less likely to create drag and drop installations and more likely to scatter files everywhere as they do in Windows?
  • Reply 17 of 18
    mr. memr. me Posts: 3,219member
    Quote:

    Originally posted by Daffy_Duck

    I could be off base here but would having a package manager make developers lazy and less likely to create drag and drop installations and more likely to scatter files everywhere as they do in Windows?



    Lazy? No. Stupid? Maybe. Each MacOS X application is a bundle of subdirectories. The files stored outside the application bundle are stored in Preferences and Applicaiton Support. IMHO, there is no reason to store certain application data files in Documentsas in the case of several high-profile apps. Because the system is so well defined, there is simply no reason to splatter files everywhere. Because MacOS X does not share the Windows directory structure, developers have nothing to gain by aping the Windows directory structure. However, there is no accounting for arrogance, stupidity, or the bright idea.
  • Reply 18 of 18
    lundylundy Posts: 4,466member
    Hmmm - if they all had to use the InstallerMaker, I suppose it could warn them if they were installing anything into directories other than

    Applications

    Utilities

    Application Support/companyname

    ~/Library/Preferences/companyname or ~/Library/Preferences/com.companyname.appname.supportfilename.plist



    I don't think InstallerMaker does this, as I made an installer that put two shell scripts in ~/Library in their own folder and it did not complain.



    Quote:

    Originally posted by Daffy_Duck

    I could be off base here but would having a package manager make developers lazy and less likely to create drag and drop installations and more likely to scatter files everywhere as they do in Windows?



Sign In or Register to comment.