Hi,
The thing is: We do install the runtime packages in the IDE. And for that, they must be "designtime and runtime". If they are only runtime, the option to install them is disabled.
Now, the reason we install the runtime packages in the IDE is just so Delphi finds them, even if they are not in the system PATH. The story goes like this:
BPLs are supposed to be in the system path, so when you run an app using packages outside of the IDE, the app can find the bpls. We don't really like to dump the bpls into the default delphi folder (but that's a story for another post...), so originally we had an option in the setup to add the packages to the System path. The problem of course was that every component does the same, and the Windows path is limited to something like about 1k (path is compressed, so this isn't exact, and I don't remember the exact number anyway). So soon people was getting paths longer than what Windows supports, which doesn't give you any error, but it doesn't work.
But note that technically, changing the system path is only needed for people running with runtime packages: As long as the package is registered in Delphi, Delphi will find it in normal use, even if you don't add it to the path.
So that's the reason we mark those packages as designtime and runtime: So we can register them and people who didn't modify the system path will still be able to use them.
Now, since 6.6 we changed the system and we don't modify the path anymore. The new method came as I was thinking how much simpler this is in the unix/linux world. There you don't modify the path for every new executable, you just drop the binaries in their correct place and then create a symbolic link to /bin or /usr/bin. So thinking about it, I didn't see a reason why we can't do the same in Windows. Since Vista symbolic links are fully supported, and we could then send the bpls to the correct folder, but then add a link to the "delphi bpls" so it will be in the system path. If you are installing in XP (which you shouldn't...) then the setup just offers to modify the path as before. For newer Windows versions, we offer to create symbolic links instead.
I think the symbolic link route is the best of both worlds: It allow us to keep the bpls inside our folder, but we don't need to mess with the system path. And except for some teething problems in the first 6.6. release has been working flawlessly (you can find the posts in this newsgroup when that happened)
But it is too soon yet to know if they are a 100% perfect solution, and so at least for now and until this is more tested, I prefer to keep registering the runtime packages in Delphi. This way even if the symbolic links don't work, your apps will work fine as long as they don't use runtime packages.
About VCL_FlexCel_ComponentsDESIGN200.bpl you are completely right, it could be design time only. But I wonder if it will make any difference to you that we change that one, if we don't change the others. The reason this package is runtime and designtime is just to avoid "special cases" We need to test FlexCel in many Delphi versions (from XE to XE7 and counting), and the less special cases we have the better. So if all the other packages are runtime and design time, it made sense to make this other one too, even if technically it won't be used at runtime. One less special case to test. Given the complexity of the setup and all the existing options, I am not sure changing it to "designtime only" won't break anything, and we have to test this in all supported delphi (and c++ builder) versions. So unless it is really critical for you I would prefer to keep it as is. (the last change I made in the setup were the symbolic links, and even when I tested it here for weeks, the same day I published I started getting reports of them not working, as you can see in other posts in this group)
Regards,
Adrian.