Hi
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?
Slavek --
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
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.
Which is an approach I prefer :-)
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.
I concur! This also will make it better for people using trinity applications who are not using Trinity as a full time desktop.
Calvin
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.
Which is an approach I prefer :-)
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.
I concur! This also will make it better for people using trinity applications who are not using Trinity as a full time desktop.
I created an etherpad for potential post R14 project goals:
http://trinity.etherpad.trinitydesktop.org/51
Darrell
-
Calvin Morrison -
Darrell Anderson -
Slávek Banko