Mailinglist Archive: opensuse-buildservice (95 mails)

< Previous Next >
Re: [opensuse-buildservice] Popular branches, moving them to "official" repos
On Wed, Jun 17, 2015 at 4:21 PM, Brian K. White <brian@xxxxxxxxx> wrote:
On 6/10/2015 10:59 PM, greg.freemyer@xxxxxxxxx wrote:

On June 10, 2015 5:59:35 AM EDT, Stanislav Baiduzhyi
<baiduzhyi.devel@xxxxxxxxx> wrote:

On Monday 08 June 2015 16:02:47 Greg Freemyer wrote:

On Mon, Jun 8, 2015 at 9:02 AM, Stanislav Baiduzhyi

<baiduzhyi.devel@xxxxxxxxx> wrote:

Right. So either you haven't read my email, or you haven't checked


file for mc in factory. It has '--disable-vfs-fish' configure flag
specifically set.

Yet when you search through the OBS, there are 11 branches (or


rebuilds) of mc, 7 of them have fish enabled as the main change

over the

factory version.

Looking at the mc changelog in the devel project it says fish was
disabled due to a data loss bug:


In that case what are you asking for?

A new repo called "I know there's a data corruption bug, but I want
the feature anyway". (I'm sure there is a better name but you get



If so, there is clearly at least some demand. I'd say make the
proposal and see if it flies. Personally I avoid software with known
data corruption bugs if at all possible.

mc is just a good example, but I mean the case in general. How many
forks of
other packages with minor tuning are there? Searching for some specific

version of package is not very helpful, browsing through revision
history of
every one of those "home:/" packages is very time consuming, so it is
faster to branch and change yourself.


I clearly work with the official development versions. If I find they
don't build the way I want I branch, change, submit. In general the SR is

Thus I looked at mc to see what change was not being submitted back to the
development project a disabled feature that can cause data loss when enabled
made sense to me.

What kind of build tweaks are living in home directories? Why aren't they
being SR'ed back to the devel project?

To me anything that encourages a divergence between devel packages and
home packages is going in the wrong direction.


That is an unanswerable, infinite, open-ended question.

There are countless configuration choices, personal preferences, compromises
for practicality/maintainability, policy based choices like
including/excluding support for some optional non-oss feature, things like
agreeing/disagreeing with suse's choice of added patches, etc etc

For instance, I don't happen to like that suse hacked in SLP support into
rsync daemon. I especially don't like that this included new config file
directives that aren't in the manual or upstream or other rsyncs on other
platforms. I especially especially don't like that this broke my ability to
publish a single config file to a range of hosts that all ran otherwise
perfectly compatible versions of rsync, even though some were freebsd, sco
open server, even one solaris, and some were linux but not suse, and some
were suse. My well working system broke when the config file either failed
to contain an required directive, or contained an unrecognized directive. I
no longer remember which direction caused some of the daemons to fail to
start, since I dealt with it a long time ago by branching and building my
own rsync, and keeping it updated over time, without those SLP patches.

It's a valid thing for me the enterprise-wide architect to decide that I
want for my own reasons, and yet it's not something that suse wants or even
necessarily should want to ever accept as a SR from me. It's perfectly fine
for suse to want that service location feature. It's not a bug to be fixed.
It's also perfectly fine for me not to want it, and for it to be considered
a bug to be fixed FOR ME.

That's just one example. The potential similar ones are literally countless.


That makes sense, but it is the "infinite" set of possibilities that
concerns me.

Stas asked to have a way to manage these types of packages outside of
home projects.

If they are important enough (KDE unstable) then a OBS repository in
the main namespace makes sense.

One called "Projects with random tweaks we like" doesn't. At least not to me.

To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-buildservice+owner@xxxxxxxxxxxx

< Previous Next >