Mailinglist Archive: opensuse-kde (327 mails)

[todd rme <toddrme2178@xxxxxxxxx>]

On Thu, Aug 11, 2011 at 9:20 AM, todd rme <toddrme2178@xxxxxxxxx> wrote:
> On Wed, Aug 10, 2011 at 9:31 PM, Dirk Müller <dmueller@xxxxxxx> 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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-kde+help@xxxxxxxxxxxx