On 6/10/2015 10:59 PM, greg.freemyer@gmail.com wrote:
On June 10, 2015 5:59:35 AM EDT, Stanislav Baiduzhyi
wrote: On Mon, Jun 8, 2015 at 9:02 AM, Stanislav Baiduzhyi
wrote: Right. So either you haven't read my email, or you haven't checked
On Monday 08 June 2015 16:02:47 Greg Freemyer wrote: the
spec 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 rather 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:
expand=1
https://bugzilla.novell.com/show_bug.cgi?id=856501 http://www.midnight-commander.org/ticket/3128
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
https://build.opensuse.org/package/view_file/openSUSE:Factory/mc/mc.changes? the
idea.)
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 usually faster to branch and change yourself.
Stas,
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 accepted.
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.
Greg
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. -- bkw -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org