On Thursday 14 July 2011, Sune Vuorela wrote: > On Thursday 14 July 2011 03:42:01 Michael Jansen wrote: > > On Thursday 14 July 2011 10:49:50 Ian Wadham wrote: > > > On 14/07/2011, at 5:16 AM, Alexander Neundorf wrote: > > > > What do you think of this ? > > > > More wishes ? > > > > Should it do it in a different way ? > > > > > > Very nice. I especially like the PURPOSE concept. > > > > > > As we discussed before, in connection with use of OpenAL sound > > > in some games, could it be possible to have grades of requirement > > > in between REQUIRED and OPTIONAL? They would not bomb out > > > the cmake run, but should issue some stronger message that the > > > requirement was not met than just saying it was "optional". > > > > I would suggest RECOMMENDED. Like it works without but we think its > > really less useful then. > > > > OPTIONAL would be stuff then that enabled additional functionality that > > is not really needed for all of us. like something that add iphone > > support. not everyone has one. > > Several packaging systems has 3 levels of relations. > stuff that must be there. > RPM-language: Requires. Deb-language: Depends. > > optional stuff that should be there by default on normal systems > RPM-language: Recommends. Deb-language: Recommends > > Optional stuff that gives something extra > RPM-language: Suggests. Deb-language: Suggests. > > Maybe we could be inspired by that? > > Note that on debian systems, apt and aptitude installs Depends and > Recommends by default, and allows Recommends to be removed without > removing other package. > Yum don't know about Recommends nor Suggests and just installs Required > packages.
Thanks for the feedback :-) So, levels would be: * REQUIRED * RECOMMENDED * OPTIONAL Should the output be Missing REQUIRED packages: * A * B * C Missing RECOMMENDED packages: * E * F * G or would Missing packages: * A (REQUIRED) * B (REQUIRED) * C (REQUIRED) * E (RECOMMENDED) * F (RECOMMENDED) * G (RECOMMENDED) be also ok ? I guess the first option is easier to read (for humans), while the second would be easier to parse (for a program). Now, anybody feels like giving this a shot ? I'm maintaining that file currently in cmake, so I can simply commit/push it, and I'd happily hand maintainership over :-) Alex _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
