> During what I chose patches for 3.5.13.1, I noticed that
> filelight-l10n seems completely superfluous. Everything is already in the
> filelight. Binary package filelight-l10n even can not be installed because the
> files are in conflict with those of filelight package.
> 
> I overlooked something or it really is?

I don't know either. Possibly that is the way we originally inherited the packages? I suppose the easy solution is to not build the l10n package.

We've discussed before about removing some nominal cruft from the source tree. kuickshow is another package because those exact same sources are included in tdegraphics. Someone could argue that some people want kuickshow but not the entire tdegraphics package, but then anybody could make the same argument for all of the Trinity packages.

I would like to see, post R14, that we split packages into individual elements as much as possible. Initially that means more work for packagers, and with reorganizing the source tree, but in the long run would be easier to maintain, as well as easier for users to customize exactly what they want to install. Debugging would be easier too because we don't have to build large mega-packages to test patches against a single app.

Darrell