"You do what you can do," the saying goes. In your case this means informing the user of the information you have. The wait period is useful information. This is especially true if the user will be using this process frequently.
Obviously, the main progress bar should display the overall progress. You can't use a second progress bar if you don't have the luxury of the space or many time indeterminate operations. If you have as many as twelve distinct operations that you would inform the user of, then you won't be able to display any operation but the one you're currently working on either.
If you know an operation by a percent, you must offer it, and optionally an estimated time, too. This must be labeled beside the name of the operation, which is usually placed below the progress bar.
Armed with this information, the right strategy is to give each operation an equal share of the progress bar's width. When an operation is completed, it's segment will be filled. This means indeterminate operations will fill their segment upon completion - as if by magic; whereas determinate operations could update your progress bar on the fly, which I flatly suggest. A little more effort, but your user will be more optimistic about your time-consuming process.
If you know which operation will require the longest time then you could write a function to distribute weighting to your operations for your progress bar based on your general knowledge of them, (much like YouTube's upload progress bar, in which all video's, large or small, are represented as 95% to upload and 5% to process.) If not, or if you can place no confidence in this method, then don't worry about it. For instance, Microsoft has processes that are unevenly distributed across time and progress bars. It's important to keep your user suitably informed. And for long processes this means a full disclosure.