[packman] PMBS - quo vadis?

[Olaf Hering]

Am Thu, 23 Feb 2017 21:23:42 +0100
schrieb Stefan Botter <jsj at jsj.dyndns.org>:

> So here is my wish to start a discussion about the way packages in
> PMBS will be maintained and moderated, and find a consensus. This
> includes also the question, if PMBS's packages should be reduced to
> the subset of full-featured packages openSUSE does not dare to
> provide, would it not be better for the openSUSE project to either
> maintain a separate project in PMBS beside
> Essentials/Multimedia/Games/Extra, or have the guts to create an own
> supplement build system/distribution repository beside Packman.

The current state of providing codecs, Applications using these
codecs and other interesting Applications is good IMO.

Due to its history there was lots of overlap, packages from the base
distro are also provided by packman. This is true even today for
everything up to and including 42.1. Starting the 42.2 and Tumbleweed
the remaining overlap is unavoidable because the packages build against
libraries which are naturally only in Packman. And for almost all of
the overlapping packages the sources come directly from the base distro
instead of random copies of devel projects.

In case Packman builds a package for Leap or SLE it should link to
openSUSE:Factory. This increases turnaround time in case something goes
wrong for non-Tumbleweed, but it reduces the number of needless
packages updates in case there are repeated changes in the devel
project.

Once a package is in Tumbleweed the variant in Packman should converted
to a _link and the "openSUSE_Tumbleweed" and "openSUSE_Factory_ARM"
targets should be disabled and the binariers wiped.

In general we should tell users to use 'zypper dup --from packman' to
get their codecs. Given the low number of overlaps there is no
technical reason to do something else. So far I have seen only
"emotional" arguments.

Now that lame/libmad could be provided by the base distribution a few
packages can be disabled. Unfortunately it affects just a very small
number of packages.

There are still a few cases where an overlapping package has its own
source. The most prominent is probably k3b which is in status-quo since
a long time. Given that there are few complaints about the git version
I can assume it is working well for most people. So I think Packman can
keep its copy. Given that its only about lame/mad the git snapshot
should be provided by its own name, like k3b-next/k3b-codecs-next, to
avoid that zypper dup will replace the variant from the base distro.


Regarding the goal "provide newer versions" I think that should be
handled on a case-by-case basis. There are repeated requests for the
latest libmlt/kdenlive for example. These are leaf packages, so the
copy in Packman should just be built unconditionally from the sources
found in openSUSE:Factory. Another example is linphone and its
libraries which also looks like a leaf package. In general I think there
are enough resources to provide such packages.

There is probably no need to replace the entire gstreamer stack
anymore. This is still done in 42.1 for historical reasons, everything
else rebuilds just the bad/ugly plugins from the base distro.


There should be some QA, which verifies if things are still working or
if a given package is perhaps obsolete. For example, recently I tried
xmms2 on SLE_12 and could not get it to work. It was either my fault or
it was really broken. Meanwhile it is gone. But as stated elsewhere
such removal should be announced. Another thing I came across was mpd.
While the daemon can be used again after the upgrade, some clients 
did not work. Its unclear if they ever worked, I think there is no
need to keep the Nth varaint of a mpd or irc client. But it is likely a
matter of taste.

Olaf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: Digitale Signatur von OpenPGP
URL: <http://lists.links2linux.de/pipermail/packman/attachments/20170224/4b61a04a/attachment.sig>