KDE Sub-Packaging Approach on Fedora

[Hugo Cisneiros]

On Tuesday 20 June 2006 09:16, Rex Dieter wrote:
> Hugo Cisneiros wrote:
> > I have just submitted a blog post on this:
> > http://www.devin.com.br/eitch/blog/2006/06/17/kde-sub-packaging-approach-
> >on-fedora/
> >
> > And I'm bringing this discussion into the list too. I'll paste the post
> > here too:
> >
> > KDE Sub-Packaging Approach on Fedora
> > =======
>
> ...
>
[...]

> My personal take (following one of Fedora's core mantras)... upstream,
> upstream, upstream... how does upstream distribute/package things?  IMO,
> packaging should generally follow suit, and if you don't like that, take
> your beef upstream(*).

I agree with working *always* with the upstream, but not exactly as the 
upstream. Sometimes we have to make adjustments tat fits our users needs and 
the distro layout. In our case here, we will not do something nasty and with 
incompatibilities... The package names (kdenetwork, kdeutils, kdegames) will 
remain the same (but now as meta-packages), the applications will be the 
same, the "official" packages will be the same.

The only thing that we are changing is bringing one more option to users: 
further customization of KDE applications (customization is a Really Good 
Thing), menus (cleaning up things we don't use), and benefiting users (as it 
appears they like this approach).

> (*) Unfortunately, I've seen people take this particular beef upstream
> before, and kde dev's responses are generally disappointing: they
> (generally) claim this is the job of the distro packager(s).  *sigh*.

I partially agree with them :) They package things in a really easy and 
straight-forward way. Much better than many applications out there. But they 
don't do final binary packages for distros, they do mostly source packages, 
and it's very different from binary distribution. This also gives us 
flexibility to do this meta-package approach.

It will be much more difficult if each program from a kdebranch package is 
separated on the source. We were to create each spec, compile each package, 
create each dependency. It's the same work we are doing here (but we are 
doing in only one specfile, only one proccess and only one tarball).

You know KDE rocks :) Sometimes we have to do some effort to grant users a 
better experience. I'm willing to do a little sacrifice myself, and trying to 
explain other why this is important ;)

> KDE sub-packaging is/will-be a lot more work, for what I consider to be
> little benefit: primarly less disk space used (and what's a few MB
> between friends these days?).

I agree that it's lot of more work, but I have to add that this should be 
difficult mostly on the beginning, changing specfiles, separating files, 
creating dependencies. After all that is done, they should easy to maintain 
(not as easy as the current one, but still easy).

I understand that not everyone has time or is wanting to do this dirty work, 
and that's the reason I'm already doing it, then getting feedback, then 
fixing stuff and trying to do a really quality package.

> OTOH, if package maintainers can handle the extra complexity and don't
> mind extra workload associated with supporting the sub-package approach,
> then I don't think anyone is going to tell you that you can't do it.

That's why I'm trying to advocate this here and being a little annoying :)

> -- Rex

Thanks for your feedback!

Cheers,

-- 
[]'s
Eitch

http://www.devin.com.br/eitch/
"Talk is cheap. Show me the code." - Linus Torvalds