https://bugzilla.novell.com/show_bug.cgi?id=804070 https://bugzilla.novell.com/show_bug.cgi?id=804070#c2 L. A. Walsh changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | --- Comment #2 from L. A. Walsh 2013-02-15 11:49:02 PST --- The problem is 1) with the design, and 2) saying you no longer support users updating their own system's components to later versions of those components (not older versions). Users have always had the reasonable expectation of being able to UPGRADE components on their system to the latest versions.. The problem is that you AREN'T supporting 12.1 AT ALL. USERS are expected to do their own support. YOU ARE preventing USERS from supporting themselves by preventing them from upgrading to newer, non-broken software. You can't close this out claiming it's outside your reasonable supportable use case, as you HAVE no reasonable supportable use case. There are NONE. Zero. They don't exist. You might as well claim that it is outside the list of benefits and free gifts that users are documented to receive, thus it is invalid. ??!?!? You have no such thing. It isn't outside the scop of the target product. I rebuilt the component for perl 5.16.1 for 12.1 from SuSE source packages for 5.16.x. It is a supported scenario according to what many believe: -------- Original Message -------- Subject: How to use binaries from 'future releases' on current (i.e. 12.2+factory on 12.1?) (was: How to use multi. vers. of same lib. on 1 sys.?) Date: Sun, 13 Jan 2013 22:58:07 +0100 (CET) From: Jan Engelhardt To: oS-fctry On Sunday 2013-01-13 20:30, Linda Walsh wrote:

So question -- if I build a binary on OBS -- can I specify what OS it is being built for? Or is it always going to build for factory? Yes, <repository name="openSUSE_12.2"> <path project="openSUSE:12.2" repository="standard"/> <arch>x86_64</arch> <arch>i586</arch> </repository> I.e. if I take the source rpm for "12.2/3 can I tell OBS to build it in a 12.1 environment? Yes. ==========================

I'm not alone in thinking this is a supported use case. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=804070 https://bugzilla.novell.com/show_bug.cgi?id=804070#c4 L. A. Walsh changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |REOPENED Resolution|INVALID | --- Comment #4 from L. A. Walsh 2013-02-15 16:30:58 PST --- Notice that you are not denying any factual details in my report, you are just rabidly waving your hands saying it's all my fault that I don't understand and so it can't be a valid bug. Vs. Explaining why a user should expect to NOT be able to upgrade to and use the current version of an application. You seem incapable of providing rational arguments. You TOLD me to file a bug here and supply rational, logical reasons as well as to provide a way to do what I indicated. Then you come and close out the whole thing as INVALID... Stop being a child and grow up. Let someone else comment. If you don't like my wording, HOW would you like me to clarify for you what doesn't work? I've been trying to work around this problem since last summer! You are wasting a huge amount of my time and will be waiting many others time when [if] these changes hit the main distro. It's NOT ok to claim the user can no longer upgrade or update the software on their machine. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=804070 https://bugzilla.novell.com/show_bug.cgi?id=804070#c6 --- Comment #6 from L. A. Walsh 2013-02-15 23:13:38 PST --- Maybe someone with better communication skills can either 1) understand what I am saying and explain why it is wrong to want a continuation of policies and procedures I've been used to with opensuse since suseV7.1 (~10 years). I'm not a newbie user. My major was computer science. I understand how software procedures and practices which is why I am filing a bug against whatever is preventing the problem being fixed. I REALLY don't want to move to another distro. I have liked suse/opensuse for a decade so it's not like I would WANT to move on, but what seems to be happening is an entire change in direction from openness and support of system developers and users having the best SW that was available. But now, the idea of locking users into the software versions that shipped with the original release and blaming the user when they want to run newer than from 1.5 years ago that fixes bugs affecting them, (or whatever the reason, it's a new color!) is completely alienating to developers. I have always selectively updated pieces of my system software and that has never been considered an unsupported use case (meaning that now the entire system is considered compromised). Sorry there's such a communication gap. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=804070 https://bugzilla.novell.com/show_bug.cgi?id=804070#c8 --- Comment #8 from L. A. Walsh 2013-02-17 18:46:20 PST --- Thank-you for ignoring the rants, Cristian B., The other Cristian(R) and I seemed to be butting heads on almost every issue on the lists lately, so there's some difficulty in maintaining a level head. To answer your question:

Linda, if you check "rpm -ql" of the packages blocking the perl update, you'll notice that they place files in versioned directories, for example (taken from current factory) /usr/lib/perl5/vendor_perl/5.16.2/x86_64-linux-thread-multi/.

In other words: updating perl means you have to update/recompile *lots of* packages. This is possible (otherwise updating perl in Factory would be impossible) - but it is not as easy as, let's say, updating to a new KDE version.

If you have a good idea how to make the dependencies less strict, I'm sure the perl maintainer will accept your patch.

There are 2 things that I do to deal with that issue, as I've been updating my perl like this for several years, at least (and have never had an issue with it affecting yast) -- the difference has been that I usually have done it from the sources and not tried it from the RPM's Perl's configuration script, by default, will include the previous generation's include directories, because *they* assume most people will want them and they have a high enough confidence that they will work, that they put this as a default in the "perl-for-dummies" installation script. What I usually have done after an upgrade (before if I'm more alert than I've been of late), is go into cpan and create a dump listing of all the installed modules ("cpan -a"). Then after I have installed the new perl, I first try the recompile command in cpan ("cpan -r") which "Recompiles dynamically loaded modules" -- that should fix any hiccups in dynamic compatibility. Rebuilding the opensuse modules would be an easier task...there are far fewer of them on my system than other modules. Right now, I have about 20 modules that don't want to compile and build the latest version -- I'm not sure howmany of those are opensuse packages, but to give you an idea of the likely hood of those being "important": I have 145 openSUSE module RPM's installed. (there may be more than one package in an RPM, but usually the package is named after the module -- indicating that usually it is closer to a 1:1 relation. So call 1000 of those openSUSE maybe? That's out of 6198 modules listed in my latest autobundle snapshot. Note -- the actual perl library -- for things like what gvim would use, livs in /usr/lib64/libperl.so (if you've built it generically). Vim doesn't require perl to function -- it's a runtime loadable feature -- if it doesn't load, vim still works -- some perl scripts used by some extensions to perl won't function. I just removed the ones that caused problems and that complained I had the wrong version of perl installed. (because the editor itself doesn't depend on any of those script languages -- there is no reason NOT to let it load them at runtime -- at least you will still have an editor, if not your favorite extension).. Does the above sound ignorant and unrational? As for submitting a patch. I've already been told it wouldn't be accepted -- the change TO hard coding the version dependencies came in 12.1 -- they want to keep it -- but it's BAD software practice for open-source software where users can always rebuild and install the latest versions from the sources upstream of suse -- which they are far more likely to do if suse's rpm's won't install due to interlocking version dependencies (which have been there for a while). But now they are also interlocking the binaries requiring huge amounts of software to be rebuilt. It's the interlocking binaries that is the most problematic, which they did, because they claim not doing so caused problems. However, when I asked what problems were caused or bugid's, I was met with silence. Very often at suse, I've seen problems and fault placed squarely on the wrong piece of software. Due to a bug in *grub*, xfs dropped from being the default FS, and was actually cautioned against (and said to be unsupported) as a root file system. But the problem wasn't in XFS -- but in grub. Rather than taking the approach that grub needed to be fixed before moving people onto it, the approach is to drop all other software that gets in the way. That narrow-focus attitude is creating great harm. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=804070 https://bugzilla.novell.com/show_bug.cgi?id=804070#c10 --- Comment #10 from L. A. Walsh 2013-02-19 14:14:12 PST --- Created an attachment (id=525365) --> (http://bugzilla.novell.com/attachment.cgi?id=525365) a diff to the rpm-spec file for vim to change to dynamic linking for supported libs FWIW, to give an idea of what a patch would look like to fix this problem. I'm attaching one that changes gvim to use dynamic(runtime, not load time) running of perl, python and ruby (these are the ones that are already supported for dynamic loading in the standard Vim distribution). Note that in addition to some changes in the arguments to the configure program, a hard-coded dependency for a specific perl version that was added in 12.1, was removed. The requirement for a specific sub-version of python and ruby was not hard-coded -- only the perl version had been hard-coded. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=804070 https://bugzilla.novell.com/show_bug.cgi?id=804070#c12 --- Comment #12 from L. A. Walsh 2013-02-19 18:10:57 PST --- (In reply to comment #9) bugzilla_noreply@novell.com wrote:

That sounds like a good idea when compiling your own perl, but I doubt it makes sense on a distribution level ("openSUSE 12.3 supports perl module paths from 12.2" doesn't sound too useful IMHO.

---- One of the issues you mentioned earlier for not supporting previous version paths was that each version of perl put libraries into V.Maj.min subdirectories. When it was said that perl can include previous version subdirs, it sounds like circular logic -- saying that previous version compatibility wouldn't be useful on a distribution level. But that's exactly what we are talking about -- One of the reasons given for putting the perl version in the binary is because the location of the binary directories is moved with each version. It seems that it was with that in mind, the ability to include 1 or more previous version directories became a solution to allow people to 'recently old', libs. I noted with Vim, only perl had its version locked -- python and ruby, in fact are not even included in the list of dependencies of perl. Yet they included in the same way perl is. So why perl? If perl provided a generic non-versioned link (perl.so => perl.so.5.16.2), to the versioned link, then programs like 'vim' could continue to use the generic interface, as mostly, vim's usage is for users to run their scripts -- vim doesn't require it anymore than it requires ruby or python.

From a user perspective (vs. the technical perspective, above), the reasons it makes sense when compiling your own perl to include previous recent-version lib-dirs is that there is a long lag time before all systems remake all of their extensions to exist in the new directories.

That's probably why the perl requirement is only in the vim-enhanced package, and not in the base package.

But I want to be able to use the enhanced features some of the time but not have my editor disabled if one of those requirements goes missing. On windows, Vim automatically adapts (at load time) to the absence or presence of run-time loadable libraries: iconv (international charset conversion), perl, 2 versions of python, ruby and tcl. It's been built that way for the past several years (at least for perl) --- and the makefile options are already present in the in linux rpm. ready -- they just have to be used. AFAIK, it doesn't Note -- in the patch someone added a dependency for 'systemd' -- yet vim doesn't require systemd to run. It generates a "temp-description file", that systemd can use -- but if systemd isn't there, that won't affect vim. I don't know if that was put in there just to make all packages require systemd in 12.3 or if they misunderstood what dependencies were. Vim also comes

...

I just removed the ones that caused problems and that complained I had the wrong version of perl installed. (because the editor itself doesn't depend on any of those script languages -- there is no reason NOT to let it load them at runtime -- at least you will still have an editor, if not your favorite extension)..

That probably depends on the POV. Maybe some people would say a "Recommends" is enough, and others say a "Requires" is needed because otherwise some features won't work.

If one don't install "all of suse", some features of the distribution will be missing. Is that a reason for any package in the distro to require every other package? I'm talking about hard-coded pathnames and versions being bound into the binary of vim.

...

As for submitting a patch. I've already been told it wouldn't be accepted -- the change TO hard coding the version dependencies came in 12.1 -- they want to keep it

Who is "they"? Names or, better, links to the ML archive would be helpful.

The other Christian said that any patch submitted to undo the hard-coded versioning wouldn't be accepted, because that's the way they want it -- and it's not going to get fixed.

Well, I somehow understand that - let's just say that I sometimes need some popcorn while reading your mails, which might also cause that people don't want to be involved in endless discussions with you.

Example -- how do I call a script early in the systemd bootup phase to have it mount my /usr partition before it does anything else. No one knew systemd well enough to tell me how this might be possible. I even asked, simply, how to turn off it's flipping my video mode on bootup. Again -- no one new. Once I found the time to do either of them -- the former took a few hours, the latter took a kernel regen (I removed the video driver for my card from the kernel -- so it couldn't flip the mode -- not the BEST solution, but if there is no other...?)

I met lots of the guys working at SUSE on conferences, and they are all friendly (I even survived my "1001 bugs" talk where I brought the "best" bugs onto the stage at the openSUSE conference ;-) and they know what they are doing (that is not meant sarcastic - I'm serious about that).

I have generally presumed so, but if the reasoning looks flawed and it looks like they rats running a maze because they were told to run the maze, I want to know. When I ask 'why' questions, the responses of many indicate they don't know. When I suggest alternate workaround I'm given no consideration. With systemd, they have it boot -- but they need to call & boot /usr right after udev starts -- as for some other probs -- they also need to let "LVM" start before mounting local file systems (but that's another matter). Changes seem to be getting pushed through whether they sre needed or not -- and I say not, only because I often suggest multiple way the same things could be accomplished to achieve the stated goal, yet am still given the brush off. That tends to make me not want to give up because I feel that both parties can have have what they want if they did it a different way, and to me that simply seems like the right choice? Trying to stay away from rant...... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=804070 https://bugzilla.novell.com/show_bug.cgi?id=804070#c14 --- Comment #14 from L. A. Walsh 2013-03-03 21:43:32 PST --- This from the perl bug filed related to this: bulk88 wrote: ... Due to Perl's current rapid release policy and maintenance patch policies, ABI changes in minor versions are not necessary anymore. New or radically redesigned (internally) features just dont get added anymore like they did in 5.8. If the interp ABI compatibility system is ever reintroduced (not likely), I would suggest a const table of offsets to the members in the interp library, and a "*(SV ***)(char*)my_perl+PL_ginterpoffsets[ABI_STACK_SP]" for "PL_stack_sp". ... ----- Can someone explain what the *technical* complaint or feature request here is? Are some vendor linux perl scripts in pure perl hard coded to check $^V/$]? Or are the vendor Perls "XS_VERSION_BOOTCHECK;" and "XS_APIVERSION_BOOTCHECK;" modified to not allow forward compatibility to newer minor releases (and when upgrading the perl to a newer minor perl, all existing XS libs won't load)? Or are absolute versioned paths to perl baked into the OS in C or on shebangs (why wouldn't symlinks fix this?)? Or I want an XS lib compiled with 5.12.4 to load into a 5.16.1 process (change the current policy so major versions are compatible)? Maybe Christian Rodriguez(crrodriguez@opensuse.org) can explain this, as he is the one who claims this is impossible to support. cr -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=804070 https://bugzilla.novell.com/show_bug.cgi?id=804070#c16 Andreas Jaeger changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED CC| |aj@suse.com Resolution| |INVALID --- Comment #16 from Andreas Jaeger 2013-03-05 17:29:15 UTC --- Looking at the upstream bug, there is some great advise on what you can do. Please follow it. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=804070 https://bugzilla.novell.com/show_bug.cgi?id=804070#c18 --- Comment #18 from L. A. Walsh 2013-03-05 11:52:31 PST --- Furthermore -- a patch HAS been submitted for gvim that allows it to work cross-generationally, 'if it can'. Has that patch been integrated? I was **asked** for a patch and was told it would be welcomed. Was that a way of trying to put me off, expecting I wouldn't submit one? Multiple projects have found that I'm perfectly capable of submitting patches on things I strongly care about. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=804070 https://bugzilla.novell.com/show_bug.cgi?id=804070#c20 Andreas Jaeger changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Critical |Normal --- Comment #20 from Andreas Jaeger 2013-03-05 20:27:04 UTC --- This is not critical according the bug definition - no data loss, segmentation fault etc. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=804070 https://bugzilla.novell.com/show_bug.cgi?id=804070#c22 --- Comment #22 from L. A. Walsh 2013-03-06 19:30:37 PST --- FWIW, the perl maintainer for the cygwin distro maintain even major release compat. I don't know how well it works, but over any short term, the effect is probably negligible. Their comments on the issue and how they achieve it (would a change in Policy.sh work on openSuSE?)... -------------------------------------- The issue is valid, but I know of no other distro other than mine, cygwin, which does provides this feature. On cygwin I do check for broken API compat within sub releases, but I guarantee that p5p does not test this when releasing a new subrelease. You, resp. upstream need to change the paths to omit the PERL_SUBVERSION, fix installperl, and ensure the proper naming of the libperl symlink. I did it via Policy.sh and a custom build script. The packager needs to ensure that no other changes crept in, like hints changes, compiler changes, arch-specific config flags. E.g. this is my @INC on cygwin with a proper upgrade strategy: i.e. ignore subrelease changes so people will not have to update all their XS modules, load older non-arch modules. perl -V: @INC: /usr/lib/perl5/site_perl/5.14/i686-cygwin-threads-64int /usr/lib/perl5/site_perl/5.14 /usr/lib/perl5/vendor_perl/5.14/i686-cygwin-threads-64int /usr/lib/perl5/vendor_perl/5.14 /usr/lib/perl5/5.14/i686-cygwin-threads-64int /usr/lib/perl5/5.14 /usr/lib/perl5/site_perl/5.10 /usr/lib/perl5/vendor_perl/5.10 /usr/lib/perl5/site_perl/5.8 -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=804070 https://bugzilla.novell.com/show_bug.cgi?id=804070#c24 --- Comment #24 from L. A. Walsh 2013-04-18 21:39:07 PDT --- (In reply to comment #23)

That's to default to using only the MAJ-MIN versions for perl's lib directories.

Sorry, left off example... for current perl, that would be just "5.16" (leave off the 3rd num). A patch for current systems to transition to that to such a system is to use symlinks for 5.16.0, 5.16.1 => 5.16.cur... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.