ok, what about this:
instead of split oscilloscope from tuna, we can abandon 'oscilloscope' subpackage
and merge it to tuna, so next version should have "Provides : oscilloscope =
%{version}-%{release}" and "Obsoletes: oscilloscope <
%{version}-%{release}", instead of oscilloscope subpackage in spec file.
this 'spec' solution should resolve base/optional channel struggles.
On Thu, Dec 05, 2013 at 10:21:12PM -0200, Arnaldo Carvalho de Melo wrote:
...
> The reason for suggesting this split is also primarily packaging
wise.
> Especially for RHEL packaging where tuna is now a "standard" package
> while oscilloscope is "optional". In addition, there's quite some
> aversion among the "management layer" for packages which have an
> explicit dependency between packages in "standard" and
"optional". So
> it's just to get resolve these issues, without introducing too many
> other challenges.
Its nice to write code, better than that is to see people feel what you
felt and keep written code alive.
Thanks,
- Arnaldo
_______________________________________________
tuna-devel mailing list
tuna-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/tuna-devel