New subject: [opensuse-packaging] Re: [opensuse-factory] why there are so few packages in Factory, revisited

1 Feb 2016

      Hello,

you might remember recent discussion in opensuse-factory mailing list on
this topic. While the statistics that started it were inherently flawed,
there seemed to be a consensus that Factory doesn't have as many
packages as it could and that there are many packages in devel projects
or home projects that are never submitted to Factory. I considered
sending my opinion why but I was afraid it might start a flame without
any positive outcome. Recent experience conviced me to try anyway.

Disclaimer: the sole purpose of this e-mail is to present my view on the
problem and to give responsible people something to think about. It is
definitely not meant as a complaint about the particular case (which
serves only as an example) or some kind of pointing fingers.

Short version: I believe main reason why too many packages never move
from home or devel projects to Factory is that on one hand, OBS made it
extremely easy to build a package for a set of distributions and even
add your own repository with such packages; on the other hand, once you
decide to get the Factory, you have to tackle constantly increasing
amount of "bureaucracy" to even get the package in and then face a
stream of pointless changes in the name of some high standards which are
apparently constantly changing and actually not even universally
accepted at any given moment.

There is a popular phrase about "scratching an itch". The problem, as
I see it, is that to scratch one's itch, home project is sufficient. If
you are an altruist, you might even push the package into a devel
project so that it stands out in the search. But getting it into
Factory, that's no more about scratching your itch; you must have really
strong motivation for that - and even stronger to do it again once you
know what you are going to face.

Let's look at an example. Few years ago, I discovered tcpreplay, a set
of network utilities which are quite handy when investigating networking
issues. I created a package, did my best to avoid OBS warnings and put
it into a project under my home so that I could easily install it on my
machines. That scratched my itch. Later some guy created a submit
request for network:utilities; I checked the package, updated it to new
versions, did some cleanup and package ended up in network:utilities.

After the December discussion, I decided to submit the tcpreplay to
Factory. I checked the build, polished the specfile a bit and submitted
it. The request was declined by a check script because a copyright was
missing. OK, fair enough, while I don't consider that particular
specfile such a great piece of art to need a copyright, why not. I ran
the specfile through the spec cleaner service (which often happens
automatically with "osc build" but for some reason this wasn't the
case). It did some rearrangement and style changes; some I didn't quite
like but nothing crucial, so I resubmitted the package.

With that submit request still waiting in staging repo, on Sunday I got
a request against network:utilities. I didn't have time to review it so
I left it to the morning. Before I could do so, 5 hours after creation
of the request, to my surprise, it was accepted by the guy who
originally poked me to submit the package to network:utilities (but
never contributed to the package in any way since).

I checked the changes anyway (after all, I'm bugowner so I feel
responsible for the package) and I really don't know what to think:

  https://build.opensuse.org/package/rdiff/network:utilities/tcpreplay?linkrev=base&rev=5

  - replace xz compressed tarball by the original gzipped one
    For years I've been told by OBS that I should repack gzipped
    tarballs to save resources. It's not true any more? OK, it allows for
    checking the signature so it makes sense.
  - make BuildRoot specification unconditional
    For years I've been told that it is obsolete. The only reason I keep
    it is to allow build for SLE11. Why forcing it on distributions that
    don't need it?
  - replace source files by full URL
    I don't like this change. More precisely: I hate it.
  - add "-q" to %setup
    Why? No idea.
  - add "V=1" to make
    Why? To make build warnings harder to see?
  - break configure line into two
    If it needed breaking, I would do so. This one had 32 characters...
    Seriously?
  - replace ${RPM_BUILD_ROOT} with %{buildroot}
    The only rule I have ever seen about this was there is no rule.
  - add %{?_smp_mflags} also to make install
    Well, why not. But definitely not _after_ the argument.
  - add LICENSE to the package
    OK, why not.
  - %files: expand wildcards to explicit lists
    Some people apparently prefer package build to fail whenever a file
    is added or renamed. I don't force them not to do so in their
    packages, could they respect my preferences in mine? Apparently not.
  - reorder tags in specfile header
    I'm confused. The previous order was what spec cleaner did. Wasn't
    it supposed to be The Right Order(TM)? And what happens next time
    spec cleaner service is run? Is it going to change the order back,
    masking real changes?

Summary: lot of meaningless churn, one useful change, two I dislike and
two (or two and a half) I really dislike. And a bad feeling that while I
took responsibility for the package, I apparently have no say in what
should its specfile look like. Don't understand me wrong: I have no
problem with reasonable rules, even if they are quite strict (like the
tagging policy in our kernel packages or strict coding style policy in
kernel networking). But here I feel this crosses a line of harassment.

OK, I'll learn to live with it. I'll bite the bullet with packages like
firebird or twinkle which are kind of "heart thing". But next time
I stumble upon a package that might be useful, I'll think twice before
submitting it to Factory. Had I known what was going to happen, well,
there would be one less package in Factory (assuming tcpreplay is going
to make it). And just today, I got a reaction like "Been there. I know
exactly what you are talking about."

Sure, you may say that it's my fault I don't understand openSUSE high
standards. You might even say openSUSE is not interested in packagers
who don't understand its high standards. But you should understand in
the end it's always packager's choice if he is going to submit the
package to Factory or not. And remember, to "scratch an itch", putting
it into a home project is enough in most cases; submitting to Factory is
not about "scratching an itch", it's about helping others; things like
this work as an active discouragement.

Think about it next time you ask yourself why so many packages stay in
home or devel project without ever being submitted to Factory. Or, even
better, think about it next time you feel urge to completely rearrange
a package you are not maintaining (and not going to) just to force your
aesthetic criteria on it (and its maintainer).

                                                         Michal Kubeček

-- 
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

[opensuse-packaging] why there are so few packages in Factory, revisited

Martin Pluskal

tags

participants (20)