Systems Management

I honestly don't know what best practice is in this regard. What I can say is that you can set up 'Requirements' and 'Dependencies' but personally I've found that this quickly becomes an administrative nightmare. For example, we set up a whole bunch of plug-ins for a product and had the main application as a requirement. When that product was updated, we had to go through nearly 60 packages to update them. Now, some will jump in here and says "supercedence" but SCCM veterans will know the pain that that causes when it doesn't work properly.

All of our packages are installed and uninstalled by a standardised set of CMDs, into which we put any pre-requisites. Presently, that means that we have some duplication in our content share (VC runtimes, for example) and may look to move these centrally, kind of like Windows Installer merge modules. The overwhelming advantage of the CMD approach is that every part or, at worst, the vast majority, of the installation can be logged, drastically reducing your debug/trouble-shooting time when things fail. The model coul easily be carried over into a set of Powershell scripts but that's a project for another day!

>If i convert the sccm package to sccm application, will the package id remain same ?
As I understand it - I've never used packages for installing software, as applications are so much more fliexible - you end up with a new application, with its own ID, based upon the package: the package remains.

The direct answers to your questions.

>the best practise of chaining ?
C̶o̶n̶v̶e̶r̶t̶ ̶t̶h̶e̶ ̶p̶a̶c̶k̶a̶g̶e̶ ̶t̶o̶ ̶a̶n̶ ̶S̶C̶C̶M̶ ̶'̶A̶p̶p̶l̶i̶c̶a̶t̶i̶o̶n̶'̶,̶ ̶s̶o̶ ̶y̶o̶u̶ ̶c̶a̶n̶ ̶u̶s̶e̶ ̶'̶R̶e̶q̶u̶i̶r̶e̶m̶e̶n̶t̶s̶'̶ ̶a̶n̶d̶ ̶'̶D̶e̶p̶e̶n̶d̶e̶n̶c̶i̶e̶s̶'̶ ̶-̶ ̶a̶s̶ ̶V̶B̶S̶c̶a̶b̶ ̶m̶e̶n̶t̶i̶o̶n̶e̶d̶.̶

Misunderstood your question. I would say don't reinvent the wheel if you don't have too, but sounds like you do have a big opportunity to work from a green field. SCCM 'Applications' does give you some flexibility in regards to prerequisites.

>if i convert the sccm package to sccm application, will the package id remain same ?
Not absolutely sure, but I know a SCCM 'Application' has its own ID.

The long answer from personal experience.

Its one of those processes that always evolving, and spending the time to design the process and tools that you are going to use, goes a long way to make it work for most of the your situations.

I recommend using using the 'PowerShell App Deployment Toolkit', from the get go. It does mean all your installers will be a sccm 'script' type install, but it will give you huge flexibility when you need it - for example when upgrading office, you can prompt the user to close stuff down, defer the install etc. Because its PowerShell, you can do inline script fixes or work arounds if you have a difficult install.  The research time into 'PowerShell App Deployment Toolkit' is about half a day to get your head around all the features and how it works - documentation is top notch.  Like everything else, it does have quirks, as with the MSI's, PSDeploy log log log to work your issues.  Lastly, think about the detection methods that you will use, it does have a impact downstream - we chose registry stamping, via PSDeploy.

Chaining, its a lot easier in sccm applications, as you set them as Dependencies - if another sccm application installed it as part of their install, sccm will detect the dependencies and skip them.

Dependencies, can have multiple options to meet requirements. For example you create a Dependency of "VC++ 2015 - 2019" which can have version VC++ v14.1 and VC++ v14.2 for it to satisfy the "VC++ 2015 - 2019" requirements. This is handy, as sometimes you dont want to update the version on the current PC for some reason or another, but moving forward you would like the newer version to be deployed. Poor example, but hope you understand the value of the option.
Im meaning this part btw:

Think carefully about how much you want to break applications apart. VC++'s are a great idea to break out, as it's shared with a lot of apps. As VBScab mentioned, other applications bits not so much. The more you break it apart, the more over head down the track with supercedence - sometimes it's just easier to deal with the application as a single deployment.

So much to mention, but I need to get back to work.

PS. If your thinking of App-V and SCCM, remember its not instant deployment like App-V Infrastructure.