Cristian Rodríguez wrote:

El 11/02/13 15:26, Linda Walsh escribió:

...

But that's why I've had all theseproblems ... no way to get from here to there...

We have explained to you ad-nauseum that there is nothing wrong with libc, whose compatibility promise is been kept under the same constrains for a decade or more.

Components other than libc have their own binary compatibility policies if any. those who dont publish any document stating a policy on this matter *must* me assumed like there is none and that ABI/API may change at will.

YAST belongs to openSuSE.. I wanted to upgrade my perl, but yast in 12.1 claims it requires perl5.14 and won't work unless I downgrade. This never used to be the case. Did OpenSuSE change policy to lock all of their own apps into each version so no versions can be used? That would be a really bad policy -- since, more than once, on upgrade, I've found a new version of "X" either doesn't work for me, or is going to take some time and effort to upgrade (samba 3.5.x->3.6.x required remaking the user database -- have seen that on the samba list from others as well). Sometimes it's samba, sometimes, it's ng-syslog, nearly every upgrade has had some issues. Gvim -- was another one -- built specifically to perl-5.14.so. But if you build it as generic "perl.so", then gvim works fine with multiple versions. Same applied for python and and another script language -- I ran into some issue with ruby (which I found a bug report on, and a workaround, but was too complicated and I was in rush, so built w/o ruby... The rest are loaded at run time -- not load time. So if they are not on the machine, at least the person can run the editor. But more importantly -- the way it is in the distro -- you can't upgrade perl. Suse had never locked specific versions of tools before 12.1, but did in 12.1 -- nearly every binary is linked with every other binary by name+version -- not just name as it used to be. Many (Most?) RPM's have had "pre-reqs" changed from some *minimum* version of a package to *exact equality*. As someone who constantly is upgrading software, having everything locked together, really is broken. Can this be fixed (obviously not overnight, but some policy needs to be reverted)... Neither the yast nor the gvim changes come from upstream -- they are suse changes. . -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Cristian Rodríguez wrote:

El 11/02/13 21:11, Linda Walsh escribió:

...

YAST belongs to openSuSE..

I wanted to upgrade my perl, but yast in 12.1 claims it requires perl5.14 and won't work unless I downgrade.

This never used to be the case.

Because Yast had and continue to have bugs, one of those bugs was the lack of strict dependency of perl versions.

I've Never had problems with yast's interactions w/perl and I'm always running non-standard versions. That goes back 10 years... It's not until you add the version numbers that I have problems and things don't work. I don't call that dumb luck --- ensuring that it won't work, though, that's sabotage... There's a been a bad trend in computers that's grown over the past several years, and that's to default to broken, rather than giving the user anything. There are some security scenarios (many) where that is appropriate, but on a home system -- it's usually not. I the system won't come up due to deliberate sabotage in version locking, then I can't fix it. Before 12.1, I used to be able to boot off of the 11.1 rescue disk (and this was a change in glibc -- I'm not saying the trend toward breakage is unique to suse). When computers first came out, the people who programmed them TRIED to make them friendly and tried to make them helpful. A PL/I compiler back in my student days used to make lots of assumptions about what you meant if you got wrong syntax ... IN PROGRAMS -- and 90% of the time it was right!.. Even in the face of errors, after it applied what it thought were the right corrections (trivial things like missing semicolons and such), it would attempt execution -- and you usually got a working (for some definition of such) program. Now, computers are being constructed to be hostile to the users -- be unfriendly and difficult to use. Just like this -- I can't mix and match versions like I have for over 10 years.. (within thought out reasons...but I majored in computer science, so not average user)... you are taking away the flexibility of unix. it was always a good and bad thing that rm -fr / just went off and did it -- you figured not to do things like that. Now the trend is to disable user control and flexibility -- turn them back into passive receivers.

...

Can this be fixed (obviously not overnight, but some policy needs to be reverted)...

Nope, at least not until perl provides properly versioned DSOs upstream. The fact that in your experiment applications worked with multiple versions is pure luck.

--- That is pure bull... Gvim has been built that way for several years on Windows and has had no major problems. Now if you have linked built code that you expect to be "hard linked" at runtime, those references can be a problem, but if you use the dynamically loaded interface, it's a lower common denominator, but it works. The Vim make/build file supports building with run time libraries but suse chooses not to use it. Vim does the same thing with python and the other scripting languages it supports. It's not dumb luck -- it was designed that way. please NOTE -- this is for the dynamicly, run-time loaded library, not the one that is autolinked by 'ldd'. Are we talking about the same thing? linux people don't seem to get run-time dynamic linking that much. Unix people did it -- and windows does it "delayed loading libraries"...but linux -- not so much...and it's a shame. those systems that use such are generally more flexible and resilient to problems in the field -- because they know enough not to expect things, but are written to check for things being there -- and if not, then not using them. Problem is programming is getting harder and harder as time goes on, and programmers are continuing to lower the bar for what they will allow and produce -- you want user friendly? You want it to correct your mistakes and just work? It's certainly a bad time computer users/owner... capitalists figured out that making software that worked well and long and didn't need upgrades was bad for business -- requiring a compute replacement of all software with every release? Perl is especially bad for you to harsh on -- they are SO conservative about backwards compatibility -- I'd love to see what some of the yast issues were that regard version issues. They maintain strict backwards compatibility for ages...and change slowly if at all. What parts of yast had problems? --- that would have been problems if you did run-time dynamic loading? As for perl's latest build scripts -- it **warned** me of using the generic libperl.so name that's been used for years -- BECAUSE of the minority of people that have problems. I'm frustrated because when these things break, I usually know how to fix them -- but when everything is interlocked and taking out 1 piece causes everything to break... That's a setup for major pain. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Mon, 2013-02-11 at 18:11 -0800, Linda Walsh wrote:

linux people don't seem to get run-time dynamic linking that much. Unix people did it -- and windows does it "delayed loading libraries"...but linux -- not so much...and it's a shame. those systems that use such are generally more flexible and resilient to problems in the field -- because they know enough not to expect things, but are written to check for things being there -- and if not, then not using them.

Hmm. I would suggest that the Linux understanding of run time dynamic linking is rather the opposite of what you think. When I make a library on Linux (GNU tools), I can leave things undefined. All functions do not need to be resolved when the library is made. They will be resolved (hopefully) when the process using the library loads the library. At that time, any remaining dynamic linking is done. This is in strict opposition to my experience on, say, Windows (GNU and MS tools act the same), where libraries need to have all symbols resolved before the library will be made. The Windows process loader will not resolve things dynamically. The DLL, AND the location in the DLL (a bane to all Windows developers) must be determined when libraries and apps are made. There is no run time dynamic linking when the process loads. Of course, you can do your own dynamic linking after the app loads, but the process loader will not do this to get the app started. This is one reason why Windows apps load faster. They are not dynamic at this stage in their life. The Linux method in fact allows run time dynamic linking to have great flexibility in how the symbols get resolved, while the Windows method allows no such flexibility. This also means that Linux has a greater chance of a mistake when library versions do not match. In your case, the problem is surely as stated: Perl is doing a crap job of maintaining application binary compatibility - which is a non-optional required property if the libraries expect to provide backward compatibility. The different versions of their libraries are not backwards compatible (read as 'new versions do not provide old features'). This lack of ABI compatibility in the Perl libraries results in the app developer being forced to require that certain versions of the library are used. The fact that earlier version of openSUSE software worked was perhaps luck. It depends on what Perl choose to change. The extent of non ABI compatibility is their decision. I think that openSUSE should instead be encouraged to find these ABI compatibility violations (which are seldom documented by the developer and thus lots of work to discover) and take the corrective actions to make openSUSE better. I am sure that they would be happier if Perl had some sort of ABI compatible method. But if Perl don't, then they must take the next best action. Complaints should surely be directed to the cause of the problem (Perl) and not the victim (openSUSE). Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tue, 2013-02-12 at 11:08 +0000, Dave Howorth wrote:

I'm not sure what you're complaining about Roger. Perl applications are written in Perl, they shouldn't have binary dependencies.

Not a complaint. I was trying to support what the openSUSE guys have done. Re Perl (and similar libs): This is not about Perl scripts. It is about programs that access Perl via a compiled library. If you link with version X, you are safest running only with that version. The complaint was that, previously, openSUSE apps like YaST did not get built so they required a specific libperl version. That has now been changed as Perl libs are not backward ABI compatible. This means that YaST requires a specific Perl version. Which is, I guess, the 'system' Perl. You are not free to change that as Perl provides no mechanism to maintain ABI compatibility in a single Perl install. So you cannot have one system Perls that is ABI compatible with previous versions.

Perl's backwards compatibility policies are set out at http://perldoc.perl.org/perlpolicy.html

Where they say they do not do backward compatibility. Which makes the currently described limit necessary. Anyway, I was not complaining. Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Linda Walsh wrote:

Dave Howorth wrote:

...

New modules can be installed either via YaST, which will result in versions compatible with system applications, or via CPAN which will result in alternate versions (usually newer). The system and alternate versions co-exist quite happily. YaST will continue to use the system versions; your programs can use the newer versions if you wish.

---

My programs are run by root and other User id's.

...

Alternate versions of perl itself can be installed but you must *not* try to change the system's perl. Use perlbrew http://perlbrew.pl/ or a homebrew layout similar to the description at

---- I was shocked on a recent upgrade to find my perl mod upgrades being redirected to my home dir (without notice).

Perhaps you should have RTFM before running the commands then. It will tell you how to avoid such self-inflicted problems. And the time you take reading may slow down the nonsense you post to this list if we are lucky. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

El 12/02/13 06:48, Roger Oberholtzer escribió:

When I make a library on Linux (GNU tools), I can leave things undefined.

Yes you can, however you should not do this unless you have a very compelling reason or we, packagers will hate you foreva :-) Fortunately the compiler and the linker currently makes much harder to do it wrong :-D

I think that openSUSE should instead be encouraged to find these ABI compatibility violations (which are seldom documented by the developer and thus lots of work to discover) and take the corrective actions to make openSUSE better.

That's the holy grail, kinda like living in the world of happy thoughts and riding unicorns .. however that's not how reality operates unfortunately.even something at a "smaller scale" such as the LSB, which tries to define an "standard" ABI for a subset of components is gonna fail (or lets say has failed) miserably. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Roger Oberholtzer wrote:

On Tue, 2013-02-12 at 17:30 -0300, Cristian Rodríguez wrote:

...

El 12/02/13 06:48, Roger Oberholtzer escribió:

...

When I make a library on Linux (GNU tools), I can leave things undefined. Yes you can, however you should not do this unless you have a very compelling reason or we, packagers will hate you foreva :-)

We do not do this. Our Makefiles are used to generate both Linux and Windows binaries (MinGW). So they do what is needed to work for both. So, we specify libraries when making libraries.

If you want to build for portability, that's the way to go. If you want Tivoize a system that makes it difficult or impossible for a user to upgrade, but can be upgraded by the "suse-build-tools" (if you have access to them -- for some people they don't work, but that's presuming your access wasn't cut off for some reason), then you use signed binaries that all interlink with versions now, but later, checks of the signatures. MS already has this option -- but it's not ever used with user systems that I know of. In fact MS has gone the extra mile to make sure that multiple versions of the same libraries can live side by side, because in real life -- people are still running XP apps on Win 7 and probably win8. Opensuse is guaranteeing the obsolescence of each release by making it binary incompatible with previous releases. Christian said this: See, all dependencies on system libraries must be known by the package manager, the build system etc.. so, all needed libraries get installed or recommended and the build system knows when and how to rebuild stuff.. problem is.. RPM does not account for dynamically loaded libraries/modules.. so esentially you are on your own. --- Sounds like a bug in RPM. In fact, the biggest bug in RPM, appears to be your claim that you can't have multiple version of the same software installed on a machine and have software link with the appropriate version at run time. I don't see why you don't hard code the load time library version number you want into the link phase. Just stop linking with libc.so.6 or libperl.so Why can't you do this: -rwxr-xr-x 1 1960896 Jul 15 2012 /lib64/libc-2.15.so* -rwxr-xr-x 1 1966974 Oct 11 23:35 /lib64/libc-2.16.so* -rwxr-xr-x 1 10160535 Jan 16 17:24 /lib64/libc-2.17.so* lrwxrwxrwx 1 12 Jan 30 02:15 /lib64/libc.so.6 -> libc-2.17.so* --- Let multiple version of a library install -- and if your code need a specific version, then link to the non-generic name. Same with perl. You would be loads better off than you are now -- because now, you are embedding those specific versions into each generic and linking all your apps with the generic name, guaranteeing that a user can't update *their* system libraries without the distro having a hissy-fit. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Am 14.02.13 13:10, schrieb Roger Oberholtzer:

Then, the libXX folk must ensure that the 2.15 version of their library is ABI compatible. When that changes, they should bump the version.

They don't. In order to not have to bump the soversion, which in the past caused many problems, libc started to use symbol versioning. This means that every externally visible symbol (e.g. variable, constant, function) gets a version. Any time the symbol changes in a way that changes the ABI that symbol version changes. Tools such as nm orj objdump will show you the versions. Philipp -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Cristian RodrC-guez wrote:

On 02/14/2013 08:40 AM, Linda Walsh wrote:

...

Opensuse is guaranteeing the obsolescence of each release by making it binary incompatible with previous releases.

OK, I'm done with you Linda, I explained to you how things work, why they work that way, and the tradeoffs involved between making a distribution easy to use,upgrade and develop

under the assumption users will not try to do insane things like what you are clearly doing and must assume you are on your own. ==== The things that you call insane are normal practice to computer people. They assume distributions won't interlock the binaries to specific versions -- if they NEED to do that, it is known you either include the lib in a program-private directory, OR you statically

You are not making it easy for users to use, upgrade and develop on. You are making it easier for yourself at the expense of users. link. But you don't screw over the user's ability to upgrade their software from sources as you have done now. You seem to have forgotten something, - and that is that distro's exist to benefit the users -- to make their life easier -- they don't exist to make their own lives easier at user's expense. That used to be a quick route to losing users -- but given the widespread cult of apple and walled-gardens, most don't care anymore -- that doesn't mean it's insane to still want the freedoms that have been on suse for over 10 years. That suse is changing to releases that users cannot modify seems like you are moving toward suse as an appliance base -- that can't be modified by users -- they will just be "users"... Suse catered to developers at one point as well as well as leaving the door open for those who use their systems as a server -- or is that crazy too? Maybe suse is only focusing on the desktop appliance route. As for reasons why suse has problems with software breakage --- I've been seeing alot more 'deprecation' and no longer supported messages out of the builds of products i've done as well as udev messages about unsupported messages in suse's udev configs. Perhaps using features beyond their usable life has something to do with your binary api problems? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2/14/2013 2:07 PM, Cristian Rodríguez wrote:

El 14/02/13 14:20, Linda Walsh escribió: if they NEED to do that, it is known you

...

either include the lib in a program-private directory, OR you statically link.

Ok, to get rid of your illusion, the best way we can do it is by trying to statically link a simple "hello world" program.

cat getpwnam.c #include #include #include

int main(void) { struct passwd *p;

if ((p = getpwnam("root")) == NULL) perror("getpwnam() error"); else { printf("getpwnam() returned the following info for user root:\n"); printf(" pw_name : %s\n", p->pw_name); printf(" pw_uid : %d\n", (int) p->pw_uid); printf(" pw_gid : %d\n", (int) p->pw_gid); printf(" pw_dir : %s\n", p->pw_dir); printf(" pw_shell : %s\n", p->pw_shell); } }

This is trivial program, which is ridiculously simple compared to a real life software.

gcc -static getpwnam.c

/tmp/ccAf3rHn.o:getpwnam.c:function main: warning: Using 'getpwnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking.

See now that your supposed approach to avoid "lock-in" and to provide "portability" is doomed ?

Here you have a non-complete or exhaustive list on why suggesting "static linking" to solve a problem is fooling yourself

http://www.akkadia.org/drepper/no_static_linking.html

Suggesting to use static linking in a distribution or in a production deployment is absolute madness as that means we must rebuild, re-test, republish all affected programs when a security problem or bug is found in a library.

To put an end on this discussion, I must say the problems you are facing are of your making due to the twisted crazy understanding of how the system really work or must work.

I rest my case.

Neither of you two are fully right or fully wrong, but she is more right than you. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2/14/2013 4:18 PM, Cristian Rodríguez wrote:

El 14/02/13 18:01, Brian K. White escribió:

...

Neither of you two are fully right or fully wrong, but she is more right than you.

No, she is not or at least has failed to do her homework before posting imflamatory accusations of lock-in, closedness etc..

- fails to understand what are the basic supported scenarios.

- fails to understand how modern linux distributions work, or that very few of them now aim to be remotely similar to an old unix system.

You fail to understand that if you want to make a new and non backwards compatible computing environment, you should make up a new name for it instead of falsely advertizing that it is something that it is not. Android and webOS don't say "linux" anywhere in their marketing materials. They say android and webos.

* If you want that, you need a source based distro or a BSD.

* this trend of dissasociation with unix or BSD will continue going further, it is part of the evolution of the distribution ecosystem.

- fails to provide any solution to a problem, probably because the problems posed are of her own making or are outside of any remotely supportable use case or scenario.

She just wants to get get actual work done, which she was _already_ doing for decades, not some strange new idea that you could at least theoretically say "you're not supposed to do that". Some of her problems are self-inflicted I agree. People get a little rough around the edges when you punch them in the nose by breaking established conventions, _especially_ needlessly. We are all engineers enough to know that the breakage is needless. You want, I have no idea what you want, but you've failed to explain how it justifies trampling all over users lives. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Cristian Rodríguez wrote: ---- It's so nice to be able to see your last name instead of a bunch of diamonds. Seriously... that perl had been forceable broken -- I majorly complained to the perl community that they were not playing ball -- that all the major apps paid attention to LOCALE settings, except for perl. But perl I/O is broken by default to be non-symmetric in a unicode environment, because it breaks UTF-8 encoding in the range 128-255. (it uses LATIN-1) because the code-point numbers are the same -- but that doesn't change the fact that it messes up documents -- that wouldn't have happened if they stuck with binary OR moved to UTF-8. But the got in the middle and stuck with binary <256, and UTF-8 >255, So in most modern unix systems it's just wrong. In 5.16, if you put "use 5.16" or some use feature thing at the top of your file, it gets it right again... which it hasn't since 5.8.1 That perl is the app you choose to call unstable I find ironic. The last thing that happened was I asked them about moving database description manpages from section 1 to section 5... or about devices to section 4 ... but I was told perl has always put it's manpages in section 1, so to change it might cause confusion. I described the perils of a complete and absolute resistance to all change, with a story relayed to me in a driver's ed class about somemone who insisted on barreling down a road because he was the first and it didn't matter that they put in a stop light after him being there for 30 years.. he would still run it... and the 5-yr-old girl crossing on walk didn't know he was suppose to be given the RoW, even if she had seen him. So not changing, *at all* is bad too. (and that got me kicked from the p5p list).. You guys are polar opposites -- your level of change approaches chaos, theirs parallels the dinosaurs. Even their high priest, like guido van r. w/python, realized that the first design had some nasty flaws that people now called sacred features. Unlike the python folks, the perl folks were far more conservative and bailed on Larry's devel, w/perl6 still not quite ready for prime time (that I've heard, anyway -- some might disagree). The wouldn't even allow "features" in places where there were CURRENTLY errors. I.e. no one could really said to be "relying" on the bad behavior, as it produced garbage and warnings. OTOH, when they DO change something, they usually give notice about 2-3 years in advance... (2-3 releases).... They make it clear. Vs. w/Suse, it's become Caveat Emptor.

El 14/02/13 18:42, Brian K. White escribió:

...

You fail to understand that if you want to make a new and non backwards compatible computing environment, you should make up a new name for it instead of falsely advertizing that it is something that it is not. Android and webOS don't say "linux" anywhere in their marketing materials. They say android and webos.

It is backward compatible under the constrains I have already explained, which are the same since years and years this is nothing new.

--- Backwards compatible openSUSE means I can recompile and reinstall portions of the **open source*** from scratch, when I need a newer version that what is included the distro. I want to maintain my ability to compile and run my own kernel. I've found I consistently get better performance and hardware utilization with such. But is not ok to force people to lock-step upgrade EVERYTHING with each revision. You've even changed the idea of what versions mean. With no difference now between major and minor versioning. Most people would call that insane.

...

You want, I have no idea what you want, but you've failed to explain how it justifies trampling all over users lives.

Nobody is trampling over users lives, or forcing anyone to do anything, it is free software, those who dont like the current state of things or the direction it is going are invited to.

---- Sorry, ANY argument I make ... like I'd like to update perl, or I'd like to run with a vanilla kernel optimized for my system and it's HW.. is considered "irrational" by your definitions. I have bugzilla'd multiple times -- for years I pushed for nscd to run as a separate user and group than just daemon/daemon. I was told unscd was the way to go -- then later, that nscd had to run as root to support nss. I said I didn't need nss. I have dns and files for my few systems and that's fine. No choice...

- Make rational arguments and workable suggestions in the proper channels or venues (i.e bugzilla)

---- One tiny voice yelling against the storm...

- Actually DO SOMETHING instead of complaining.

I try to do what I can. Which isn't much. I'm disabled from RSI and back problems which limit time I can spend and slow down my work by 4-10x over what it used to take me to do things...and it drives me crazy. But with the changes in suse lately, I'm going backwards faster than I am going forwards... I'm not getting to do the things I want to do -- I'm having to work on fixing problems most of the time.

- Choose another linux distribution, for the needs mentioned in this thread , it has a to a source based one or a BSD.

Opensuse was fine when it was ***OPEN*** and didn't have everything linked together -- and rpms would just build if you had the prereqs installed. Now you need a special system to build, and I'll bet money when you run the tests that come with those products -- you also run those tests in an artificial, isolated, "non-real world".... That's why the quality had dropped and you having the problems you are having. The openSuSE approach over the past few years has been attempting toward increased control -- first the build & test env -- then the requirement that you NEED a non-real world system to build things on (combined with the fact that you don't even TEST building your SW with a fully installed development system. Now you are working on controlling the user's execution environment as well -- by forced version-linking. That's not robust software. That's fragile software built to operate in an artificial environment. I have all the source rpms installed for suse, but starting with 12.1, I am no longer able to build many of them as they don't build except on a suse approved environment -- how this isn't more tivoization, I don't know. Multiple times I've tried to get OBS to work over ssh.. never had luck. I was even told I could build 5.16.0 for my 12.1 system -- but when I asked for more information or how to do it, people fell silent. Now I know why -- it wouldn't have worked. Nevertheless, I can configure DNS/bind, and run my own domain (tiny)... I can configure samba as a domain server; sendmail to send my mail, squid to act as my proxy, BOTH winXP and Win7 being roaming clients that had their home directories saved on the server (mostly because I didn't trust win7 with my data)...and most recently have gotten my win7-server link upto 400MB/s R/W over samba!.... But OBS?... not that I haven't tried... but it sounds like it might not help anyway... someone else told me I could build 5.16 (perl) for my system... sounds like that's not right (and I don't mean a private build, since much of my system operation is done through scripting I've written in shell or perl -- but that means my scripts run at the system level. That suse claims users running their own system scripts is unsupported is a major shift from the past -- it's not me that is "insane"...though I could see why you would want to portray me that way. If people actually realized the way you are going opensuse will be more closed than MS -- at least there I can install my own perl and not worry about MS saying I'm on my own because of it. Sheesh! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

El 15/02/13 16:02, Linda Walsh escribió:

Cristian Rodríguez wrote:

...

Nobody is trampling over users lives, or forcing anyone to do anything, it is free software, those who dont like the current state of things or the direction it is going are invited to:

- Make rational arguments and workable suggestions in the proper channels or venues (i.e bugzilla)

- Actually DO SOMETHING instead of complaining.

---

Made rational arguments and workable suggestions and filed them in https://bugzilla.novell.com/show_bug.cgi?id=804070

Since that is not a proper bug report (it is more like a rant really) it does not have a proper scope and it is outside the supported scenarios it is an INVALID report. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

El 15/02/13 16:55, Linda Walsh escribió:

It's filed about a development problem in suse 12.1.

Development of openSUSE 12.1 is closed, nothing there will be ever fixed other than security problems.

Other people on the factory list have said that rebuilding newer versions of the sources for a 12.1 target is full supported in OBS.

Correct, the OBS provides you with the proper environment and the constrains and will tell you if what you are doing will fly or not (or better said, if it will compile or not, not if it will work) but that is not remotely similar to what you are doing. You are trying to do all sort of weird things that are completely out of the scope of what is supported, usable or that may even work. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thu, Feb 14, 2013 at 3:42 PM, Brian K. White wrote:

You want, I have no idea what you want, but you've failed to explain how it justifies trampling all over users lives.

Concern troll is obvious. Can you and Linda please go use something else? Debian won't be adopting systemd and they have no plans for a /usr merge. Perhaps the two of you can find a home over there. http://www.debian.org/ -- Chris -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2/14/2013 9:01 PM, Christofer C. Bell wrote:

On Thu, Feb 14, 2013 at 3:42 PM, Brian K. White wrote:

...

You want, I have no idea what you want, but you've failed to explain how it justifies trampling all over users lives.

Concern troll is obvious. Can you and Linda please go use something else? Debian won't be adopting systemd and they have no plans for a /usr merge. Perhaps the two of you can find a home over there.

http://www.debian.org/

Why do you think I haven't been too active here lately? -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Am 14.02.13 18:20, schrieb Linda Walsh:

They assume distributions won't interlock the binaries to specific versions

Just accept that libc is special in that every program in your system uses it. Another example would be libgcc.so, the shared library that is part of gcc. This library may only exist once in a system so that things like exception handling works across multiple binaries. -- if they NEED to do that, it is known you

either include the lib in a program-private directory, OR you statically link.

These both are band aids at best. Lib in program-private directory is mostly used in Windows and is part of the reason for the dll hell problem. Static linking can be a solution, though it creates a maintenance nightmare, and you can't statically link to libc if your code uses any function for name resolution like gethostbyname(3).

That suse is changing to releases that users cannot modify seems like you are moving toward suse as an appliance base -- that can't be modified by users -- they will just be "users"...

I don't know in which parallel dimension you've been living but the current situation hasn't changed in the 18 years I use linux and the roughly fourteen years I'm working for SUSE.

As for reasons why suse has problems with software breakage --- I've been seeing alot more 'deprecation' and no longer supported messages out of the builds of products i've done

What you call SUSE problems is first of all the problem of those that maintain a given package and many if not most of them don't work for SUSE.

as well as udev messages about unsupported messages in suse's udev configs.

See above.

Perhaps using features beyond their usable life has something to do with your binary api problems?

How many times do we have to tell you that you're barking up the wrong tree? Complain to those that maintain the upstream version of a given library! A distributor can't do that work simply because of the resources this would need. Even debian can't and won't do it. Philipp -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org