[opensuse-kde] kde4-filesystem
Can somebody explain the purpose of kde4-filesystem? I am unclear, for example, why the library directories are generated there rather than in the kdelibs package, or why, for example, obsoletes of kdsdk4 packages are put there rather than kdesdk4. I know that things like the macros need to be installed, but I am not clear why directories and obsoletes are placed there rather than with the packages that need them. -Todd -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On Tuesday 09 August 2011, todd rme wrote:
Can somebody explain the purpose of kde4-filesystem?
it is a central package that has multiple purposes: - define common macros for all kde like packages - define ownership for common directories for all kde packages
for example, why the library directories are generated there rather than in the kdelibs package, or why, for example, obsoletes of kdsdk4 packages are put there rather than kdesdk4.
Because kdesdk4 does not exist anymore, so something has to obsolete it. Is there a problem with that? Thanks, Dirk -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On Wed, Aug 10, 2011 at 9:31 PM, Dirk Müller <dmueller@suse.de> wrote:
On Tuesday 09 August 2011, todd rme wrote:
Can somebody explain the purpose of kde4-filesystem?
it is a central package that has multiple purposes:
- define common macros for all kde like packages
Yes, I said I understood this.
- define ownership for common directories for all kde packages
This, in some cases, is something I don't understand. For example, why are the kdelibs directories not defined by kdelibs? Or the oxygen icon directories not defined in the oxygen icons package? It seems that having the directories separate from what actually uses them makes the packages more difficult to. It also adds needless dependencies for users. Why do users need to worry about rpm macros unless they are building packages?
for example, why the library directories are generated there rather than in the kdelibs package, or why, for example, obsoletes of kdsdk4 packages are put there rather than kdesdk4.
Because kdesdk4 does not exist anymore, so something has to obsolete it.
Maybe that isn't the best example. How about libkscan4? This is already provided and obsoleted by kooka. Or kdedue4. Shouldn't this be obsoleted and provided by libkdeedu4?
Is there a problem with that?
I'm trying to do a cleanup of the KDE packages (RPMLINT errors, formatting issues, macro usage, etc) and I am trying to understand what I should and should not be cleaning up in this package. The obsoletes, in particular, lead to a lot of unnecessary rpmlint errors. If these were, wherever possible, put in the appropriate packages, then they could also give the necessary "provides", but adding provides to kde4-filesystem is definitely wrong, since it doesn't really provide anything. -Todd -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On Thu, Aug 11, 2011 at 9:20 AM, todd rme <toddrme2178@gmail.com> wrote:
On Wed, Aug 10, 2011 at 9:31 PM, Dirk Müller <dmueller@suse.de> wrote:
On Tuesday 09 August 2011, todd rme wrote: - define ownership for common directories for all kde packages
This, in some cases, is something I don't understand. For example, why are the kdelibs directories not defined by kdelibs? Or the oxygen icon directories not defined in the oxygen icons package?
It seems that having the directories separate from what actually uses them makes the packages more difficult to.
Sorry, that is supposed to be "more difficult to maintain". -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On Thu, Aug 11, 2011 at 9:20 AM, todd rme <toddrme2178@gmail.com> wrote:
On Wed, Aug 10, 2011 at 9:31 PM, Dirk Müller <dmueller@suse.de> wrote:
On Tuesday 09 August 2011, todd rme wrote:
Can somebody explain the purpose of kde4-filesystem?
it is a central package that has multiple purposes:
- define common macros for all kde like packages
Yes, I said I understood this.
- define ownership for common directories for all kde packages
This, in some cases, is something I don't understand. For example, why are the kdelibs directories not defined by kdelibs? Or the oxygen icon directories not defined in the oxygen icons package?
It seems that having the directories separate from what actually uses them makes the packages more difficult to.
It also adds needless dependencies for users. Why do users need to worry about rpm macros unless they are building packages?
for example, why the library directories are generated there rather than in the kdelibs package, or why, for example, obsoletes of kdsdk4 packages are put there rather than kdesdk4.
Because kdesdk4 does not exist anymore, so something has to obsolete it.
Maybe that isn't the best example. How about libkscan4? This is already provided and obsoleted by kooka. Or kdedue4. Shouldn't this be obsoleted and provided by libkdeedu4?
Is there a problem with that?
I'm trying to do a cleanup of the KDE packages (RPMLINT errors, formatting issues, macro usage, etc) and I am trying to understand what I should and should not be cleaning up in this package.
The obsoletes, in particular, lead to a lot of unnecessary rpmlint errors. If these were, wherever possible, put in the appropriate packages, then they could also give the necessary "provides", but adding provides to kde4-filesystem is definitely wrong, since it doesn't really provide anything.
-Todd
Alright, so here is specifically what I am thinking for kde4-filesystem (besides some formatting changes): First, as we discussed already, remove the obsoletes for early versions of KDE 4. I think a good rule of thumb is to removes obsoletes for any version of KDE shipped with openSUSE releases prior to the last deprecated one (so anything before 11.2 or 4.3 in this case). That leaves these obsoletes: Obsoletes: kpilot <= 4.3.80 Obsoletes: kdeedu4 <= 4.6.80 Obsoletes: kdeedu4-noarch <= 4.6.80 Obsoletes: kmtrace-devel <= 4.6.80 libkeedu4 already has obsoletes and provides for kdeedu4 and kdeedu4-noarch, so I think that is redundant here and can be removed. Along the same lines, there is still a kmtrace package, so I suggest moving the kmtrace-devel obsoletes to kmtrace and adding a provides there. That would leave kpilot, which has been flat-out removed upstream for lack of a maintainer. Since there isn't any equivalent KDE software right now, I think that can stay where it is (until 11.4 is no longer maintained, since kpilot was abandoned for KDE SC 4.4/openSUSE 11.3). The next issue is the directories. With the move to kde frameworks, it is probably a good idea to keep the library directories as-is because we can no longer count on there being a single, unifying library package. The same is true for many other directories, it is hard to tell what will happen to them with frameworks. There are two exceptions, though, in my opinion: 1. The oxygen icon directories seem like they should be created and owned by the oxygen package. If programs want to use the oxygen icons they should depend on them. So I think that having this may mask packaging problems and should probably be avoided. 2. This is even more the case with the phonon backend directories. A phonon backend is useless without phonon and vice versus, so I think that having the phonon package create and own that directory would once again be a good idea. The rest would stay as-is. -Todd -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On Tue, Aug 23, 2011 at 12:51 PM, todd rme <toddrme2178@gmail.com> wrote:
On Thu, Aug 11, 2011 at 9:20 AM, todd rme <toddrme2178@gmail.com> wrote:
On Wed, Aug 10, 2011 at 9:31 PM, Dirk Müller <dmueller@suse.de> wrote:
On Tuesday 09 August 2011, todd rme wrote:
Can somebody explain the purpose of kde4-filesystem?
it is a central package that has multiple purposes:
- define common macros for all kde like packages
Yes, I said I understood this.
- define ownership for common directories for all kde packages
This, in some cases, is something I don't understand. For example, why are the kdelibs directories not defined by kdelibs? Or the oxygen icon directories not defined in the oxygen icons package?
It seems that having the directories separate from what actually uses them makes the packages more difficult to.
It also adds needless dependencies for users. Why do users need to worry about rpm macros unless they are building packages?
for example, why the library directories are generated there rather than in the kdelibs package, or why, for example, obsoletes of kdsdk4 packages are put there rather than kdesdk4.
Because kdesdk4 does not exist anymore, so something has to obsolete it.
Maybe that isn't the best example. How about libkscan4? This is already provided and obsoleted by kooka. Or kdedue4. Shouldn't this be obsoleted and provided by libkdeedu4?
Is there a problem with that?
I'm trying to do a cleanup of the KDE packages (RPMLINT errors, formatting issues, macro usage, etc) and I am trying to understand what I should and should not be cleaning up in this package.
The obsoletes, in particular, lead to a lot of unnecessary rpmlint errors. If these were, wherever possible, put in the appropriate packages, then they could also give the necessary "provides", but adding provides to kde4-filesystem is definitely wrong, since it doesn't really provide anything.
-Todd
Alright, so here is specifically what I am thinking for kde4-filesystem (besides some formatting changes):
First, as we discussed already, remove the obsoletes for early versions of KDE 4. I think a good rule of thumb is to removes obsoletes for any version of KDE shipped with openSUSE releases prior to the last deprecated one (so anything before 11.2 or 4.3 in this case).
That leaves these obsoletes: Obsoletes: kpilot <= 4.3.80 Obsoletes: kdeedu4 <= 4.6.80 Obsoletes: kdeedu4-noarch <= 4.6.80 Obsoletes: kmtrace-devel <= 4.6.80
libkeedu4 already has obsoletes and provides for kdeedu4 and kdeedu4-noarch, so I think that is redundant here and can be removed. Along the same lines, there is still a kmtrace package, so I suggest moving the kmtrace-devel obsoletes to kmtrace and adding a provides there.
That would leave kpilot, which has been flat-out removed upstream for lack of a maintainer. Since there isn't any equivalent KDE software right now, I think that can stay where it is (until 11.4 is no longer maintained, since kpilot was abandoned for KDE SC 4.4/openSUSE 11.3).
The next issue is the directories. With the move to kde frameworks, it is probably a good idea to keep the library directories as-is because we can no longer count on there being a single, unifying library package. The same is true for many other directories, it is hard to tell what will happen to them with frameworks. There are two exceptions, though, in my opinion:
1. The oxygen icon directories seem like they should be created and owned by the oxygen package. If programs want to use the oxygen icons they should depend on them. So I think that having this may mask packaging problems and should probably be avoided.
2. This is even more the case with the phonon backend directories. A phonon backend is useless without phonon and vice versus, so I think that having the phonon package create and own that directory would once again be a good idea.
The rest would stay as-is.
-Todd
So does anyone have any thoughts on this proposal? In general, it would probably be a good idea to have some sort of general idea about how long obsolets/provides for past software should be kept. Having obsoletes/provides for name changes made in th KDE SC 4.0.x cycle doesn't make much sense, obsoletes/provides for name changes in the 4.3.x cycle probably doesn't even make sense. -Todd -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
participants (2)
-
Dirk Müller -
todd rme