These are the functional benefits I'm aware for using the Software Library over a UNC path.
 
When you import an MSI or EXE into the library, the Importer tries to detect the following items:

• Command lines available for Install, Uninstall, and Repair
• MSI Product Code detection rule (MSI only)
• Product
• Manufacturer
• Version

 
These options would need to be set manually otherwise. Also a  MD5 hash for every program file is created, but I'm not aware of the reason or benefit behind this at the moment.

We went from using UNC paths in NS6 to the software library in NS7 - we've imported about 300 software resources.

If I had the option, I would definitely go back to using UNC paths.

All the software import function is really doing is copying your package from one section of your networked storage to another. If you start trying to import really big packages, like the Adobe CS3/4/5 suites, NS7 will freak out and the import can fail (after taking over an hour to copy).

Once copied, it is placed in a folder with an exceptionally inconventient 32 character GUID for it's name. This makes it really hard to try and find a specific package in the library. I usually resort to running a search for the name of the MSI or something specific (searching for setup.exe returns a heap of results).

As for what TGiles stated, this is true, in a way. If you import an MSI or an EXE, it will create a default install command. I've yet to ever be able to use it however. Every package requires me to go in and remove some logging from the command, or change one of the switches. I've ended up creating a new install command for every package anyway.

In terms of the hash, I'm pretty sure all that is for is to confirm that the initial copy from a to b was successfull. I've edited packages post import and it doesn't seem to affect anything.

The product name you will need to edit 99% of the time, as with manufacturer and version (this isn't Symantec's fault though - just lazy packagers). 

If you set a VB script as your install, you wont get anything populated.

UNC paths mean you can have informative folder names for each of your packages. It allows you to go in an make modifications easily and also track and organise what you have in your library.

If you delete a resource from the software library through the NS7 interface, it will not remove it from wherever it is storing the package. We have about 100 redundant folders in our software library already - and we aren't even in production yet!

Sorry if I sound so negative. It's just that it's been my one major issue with NS7 so far.

is you can use MST files in custom commands
https://www-secure.symantec.com/connect/forums/pro...

It assists in populating the software catalog. That becomes a much bigger issue\benefit when implementing Asset Management. You have all brought up some excellent points worth considering.

I needed to modify this as my statement, as any method of import (or even inventory scanning) should populate the software catalog.

I was under the assumption that any imported software would be put in the catalog whether it was in the official Definitive Software Library or not.

and hopefully my (newly revised) statement is correct now as well.

Are there any other comments on this topic?  Do any product or support engineers have anything to add perhaps?

I don't where to do that in the edit package page.  There is no button for uploading or adding files

EDIT: Never mind, I was looking at editing a package sourced from a UNC.  The interface is different depending on where it is sourced.
.

Recently posted to the Knowledge Base

Thanks for posting that.  I was reading it and it confirmed what Jeff posted (so he gets the solution!).