[packman] PMBS - quo vadis?

[Manfred Hollstein]

Hi there,

first of all I'd like to heartfully thank you, Stefan, to start this
discussion. It happened too often during the past months (actually since
TW arrived), that software cannot be installed due to the reasons you
explained very clearly.

On Fri, 24 Feb 2017, 10:29:16 +0100, Stefan Botter wrote:
> Hi Tomáš, (and of course all other list subscribers),
> 
> thank you for your reply.
> 
> On Thu, 23 Feb 2017 22:03:28 +0100
> Tomáš Chvátal <tomas.chvatal at gmail.com> wrote:
> > [...]
> > With the cleanups of Essentials now happening only actual packages
> > that were cut without main openSUSE repository providing them are
> > items depending on ffmpeg-0.x which contains at least 40CVE's and
> > some remote executions among them (yes there were packages depending
> > on that which were removed, but frankly I would rather have
> > non-exploitable system, and I don't mind recreating those packages if
> > someone patches them to build with new ffmpeg). Other removals were
> > mostly based around stack that was supposed to be removed ages ago by
> > simply replacing with renamed libraries libraries. The end result
> > will simply be almost identical for end user like the current state.
> 
> It is a good idea to streamline packages, and I am happy to see more
> people engaging in packaging on PMBS. On the other hand, it would have
> been a good idea to announce this major change on the mailing list and
> wait for objections.

Exactly, this is really no way to work with a community. Especially when
functionality (or support for specific hardware in this case) gets
silently removed without announcing it first. Yes, I'm talking about the
broadcom-wl driver which got removed without any announcement. I agree
you re-added the package pretty fast when I asked if/why the package had
been removed, but this is just an example for bad communication. I would
have sent a message indicating that the in-kernel driver should support
all/most of the NICs out there, and that everybody using the
out-of-kernel package should check if the in-kernel driver actually
works for them. Only when there is consensus that that is the case, the
package can be removed. But this is just my opninion.

> >  We are grateful for the infrastructure
> > itself but simply put the growing amount of complains about the state
> > of Packman was quite dishearting for us on openSUSE side. As you say
> > Richard already raised these points 8 moths back and without seeing
> > much improvement of stability in meantime I decided to try to do
> > something about it.
> 
> As I hinted yesterday, Richard expressed the opinion, that Packman is
> merely an extension of openSUSE to do the dirty work of publishing
> software, which openSUSE does not dare to publish itself. This seems to
> be a common opinion among openSUSE supporters, as I can read from the
> real quick answers to request made by more inexperienced users in
> mailing lists or the openSUSE forum.
> "Go include Packman repo, do zypper dup and everything is working.".
> Good idea, and it worked real well a few years back, when there was no
> Tumbleweed (TW), but just the regular openSUSE releases. It took us some
> days, but then the functionality was provided.

Indeed! Another example why the current approach to rely on some
packages being provided by Factory first is kodi-17. It got build by
some fellow packager here in PMBS with an libcec version that appears to
be required kodi-17, but which wasn't available neither in PMBS nor in
OBS. So, he created his version of libcec >= 4.0, and everything was OK
for his home: project. But, when the package got moved to the Multimedia
repository, kodi-17 didn't build because the current policy appears to
dictate that libcec >= 4.0 must go through Factory first and only then
can be linked from there. We're still waiting for it to finally show up.
As a result, the corresponding kodi-17 plugins/addons, which don't need
libcec, are now being made available in a version which doesn't fit to
kodi-16, which every user still has installed. Users who currently want
to upgrade their systems from openSUSE_Leap_42.1 (or even openSUSE_13.2)
to openSUSE_Leap_42.2 get into trouble, while those users who want to
install new systems with kodi included and who happen to need one of the
addons for their e.g. DVB-C/T/S receivers, cannot install it anymore...
To be honest, since nothing in the distribution or on OBS so far
required libcec >= 4.0, I really cannot understand why we couldn't
simply put it into Packman, as it used to be done a long time before,
and it used to work then!

> And not only this, but as especially multimedia packages are moving
> forwards rapidly, Packman provided the things and versions openSUSE was
> to slow or inflexible to provide. There are still packages in the
> repos, which are there in the way they are for a reason.
> 
> Richards objected to the way Packman selected its packages, with
> respect to TW. Packman either used package sources hosted and
> maintained on PMBS, or used linked packages from OBS' factory. 
> This yielded in package versions, which were ahead or behind of TW, and
> TW users complained, that Packman broke their system. We should sync
> with TW versions. The problem there is, that once TW is available, it
> is available to its users, and just then for PMBS to build its own
> full-fledged versions. This takes time, and TW users complain about
> Packman not providing packages fitting to their TW.

Yeah, instead of ripping PMBS, this should be addressed first.

> And here again is the misunderstanding. Packman is not just there to
> provide the same packages as openSUSE, only fully working ones. Packman
> is a repository to host interesting software, which is elsewhere not
> found. Or crippled. Or old.

And when packages get removed, again, this needs some way of
communication, potentially with reasons included and hints what should
be used instead - this can be currently seen on openSUSE_Leap_42.1 where
several gstreamer related packages (0_10 version) either would need to
get downgraded to those versions from OBS, or they don't even exist
anymore (like libaudio2 or libslv2), but are still required by other
packages (like MPlayer2).

> > If community around the packman actually decide
> > the goal is not to provide multimedia basis for openSUSE and we
> > should not strive to improve and tweak the Packman to go together in
> > the direction we envision for openSUSE we will of course stop doing
> > those changes and will have to discuss and figure out other
> > solutions, but that is something I really try to actually avoid by
> > doing this project.
> 
> We should think about this, though.
> I know, there are very few packagers here, and the glory days of a rich
> and fast delivery of new and interesting software via Packman are
> fading.
> I am asking here to find a consensus on the future of Packman and the
> packages hosted on PMBS. If there is no possibility anymore to follow
> the initial goal to provide a one-stop repo for all kind of software in
> newest versions, then we should restructure the repositories in PMBS to
> still have a small area for the "different" software with a warning,
> that installing software from these repos might break the system of
> the user. Beside that - and this is just a suggestion - we should have
> one repo to just supply the openSUSE packages, that openSUSE can still
> think, that Packman is just doing the dirty work.

To be honest, I kind of liked (and still do) the idea of having Packman
as a one-stop repo; it doesn't mean that I would be against re-using
stuff (via linking) from OBS if possible, but, if it takes forever, we
should be as pragmatic as before and provide such stuff out of PMBS.

> In any case - and let me re-iterate this - retracting rights in the
> build system of another user, just because you can and the actions of
> the other user does not fit your idea, is intolerable and not the way
> we work together.

Thanks for all your hard work, and, Tomáš, please don't take it
personally, your work and intentions are appreciated, too! But we need
to establish a better form of communication, too.

> Greetings,
> 
> Stefan

Cheers.

l8er
manfred
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.links2linux.de/pipermail/packman/attachments/20170224/c690d1b4/attachment.sig>