Patrick Shanahan wrote:

* Linda Walsh [06-09-13 11:17]:

...

Gvim, among several other suspicious packages has a dependency on systemd.

Um...why? [...]

I don't see that. After installing gvim, I ran "rpm -q --requires systemd | grep -i gvim" which provides no results. Maybe the dependency you see is somehow related to your "off-standard" manipulation of the system.

Actually it's related to the rpm.spec file and for building though for running it requires some specific version of perl but not for python/ruby. Of course, I don't see why any of those are required for *running* a text editor (dynamic load works just fine. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrey Borzenkov wrote:

� Sun, 09 Jun 2013 08:15:33 -0700 Linda Walsh �����:

...

Gvim, among several other suspicious packages has a dependency on systemd.

It does not.

Sigh... My mistake, meant to ask why systemd is required to BUILD it? %define pkg_version 7.3 %define official_ptchlvl 661 %define VIM_SUBDIR vim73 %define site_runtimepath /usr/share/vim/site Name: vim Version: 7.3.%{official_ptchlvl} Release: 2.1 BuildRequires: db-devel %if 0%{?suse_version} > 1020 BuildRequires: fdupes %endif BuildRequires: autoconf BuildRequires: gettext-devel BuildRequires: gtk2-devel %if 0%{?suse_version} > 1200 BuildRequires: pkgconfig(xt) %endif BuildRequires: ncurses-devel BuildRequires: perl BuildRequires: pkgconfig BuildRequires: python-devel BuildRequires: ruby-devel BuildRequires: systemd <<<<------------------- BuildRequires: tcl-devel BuildRequires: update-alternatives BuildRequires: update-desktop-fil ... %define vim_prereq %{name}-base = %{version} # Explicitly require versioned perl for libperl.so %define perl_requires perl = %(rpm -q --qf '%{VERSION}' perl) ---- Also why is perl have an extra check to have it require a specific minor release? It's not done for ruby or python or any of the other script languages... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Cristian Rodríguez wrote:

El 09/06/13 17:09, Linda Walsh escribió:

...

BuildRequires: systemd <<<<-------------------

There must be a reason why it is there, the buildservice is down atm so I cannot check why.

Builds just fine without it...several products had such build deps... (sorry mispoke about remembering them as rundeps... )

...

Also why is perl have an extra check to have it require a specific minor release? It's not done for ruby or python or any of the other script languages...

I dont know how many times I have explained this to you.. are you just trolling ?.. applications linking against libperl.so need requires against an specific perl version. (%perl_requires macro, which particular package defines instead of using the global version)

---- The perl developers say this isn't true. How is it that you know more than they about perl? Or are you just ignoring them? You also haven't explained why the same wouldn't be true for ruby or python. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Cristian Rodríguez wrote:

so if perl version changes, let's say to 5.16.4 , all packages that depend on it are automatically rebuilt, their dependencies updated etc.

Why? If they work with 5.16.3 5.16.2 5.16.1 or 5.16.0, it should work with 5.16.4 It's just like the glibc -- a newer version will work with the older but for perl -- only guaranteed within a major version. So 5.18 -- not guaranteed. Might work but might not. Perl has always had the option to build and include libraries from the previous versions. Suse has notably broken minor version compatibility.

If not, perl 5.16.4 will be published to users but not those who depend on it, then at startup, programs will fail to fin

/usr/lib/perl5/5.16.2/x86_64-linux-thread-multi/CORE/libperl.so that is no longer there.

They shouldn't fail to find it if perl was built correctly. But you are saying you don't know how to build it such that it would work? The

...

You also haven't explained why the same wouldn't be true for ruby or python.

rpm --eval %py_requires --> for python

--- libpython handles libpython2_7-1_0-2.7.3 2.7.1.0 - 2.7.3 So why not perl handling 5.16.0 - 5.16.3?

rpm --eval %rb19_ver --> for ruby

--- Better -- ruby only requires the perl equiv of 5.16.X... Why not have perl requires only look at the major version like ruby? Bo

This is the expected behavior from the distribution POV;

---- That ruby supports multiple minor releases, that ruby ignores minor releases and perl fails over minor releases? What distribution could justify such when perl's policy is compat within a major release?

there is nothing wrong it so it will not be changed unless you have a very compelling reason to do so (no, "I build my own packages" is not a compelling reason)

how about compat with previous version of suse where it wasn't done OR following the same rules as with ruby or python?? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Cristian Rodríguez wrote:

-User does a clean install for example openSUSE 12.3 (can be whatever version, I choose 12.3 as an example only)

- openSUSE 12.3 is unlikely to change its perl version for its lifetime, but if it does, all packages will be updated and published at the same time.

Development resources are a limited asset and number of things that can go wrong in the case you want to support a custom perl version are almost impossible to manage.

Factory built images with suse rpm files are custom? Since when? As soon as a new version comes out of MANY products, it is available for download from SuSE package search facility. You haven't explained why you don't disallow any user installed packages not included with the release. You are only doing this on perl -- you didn't explain why you support multiple releases on python and ruby among other projects. (samba, firefox, .. the list is extensive). Even libc -- you can down load a newer version and compile it w/suse's extensions and THAT works. You don't require every linked with libc to be rebuilt... That's the whole purpose of using a shared library -- or so I'm told. Yet you don't allow minor and compatible updates to perl -- alone. Your stance doesn't make any sense. Why for perl and not all the rest? Even though you've been told that the API's are compat within a major version, you refuse to allow upgrades? But do for other products? Why perl and no other language? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Cristian Rodríguez wrote:

El 09/06/13 19:19, Linda Walsh escribió:

...

Why perl and no other language?

glibc has proper symbol versioning and it is installed in the system library path, libperl does not have proper symbol versioning and is installed in a version dependent directory.

You keep leaving out ruby and python in your comparisons. They don't have symbol versioning -- and the fact that perl is put in a version dependent directory is 1) a choice in how you build it, and 2) irrelevant, as perl allows you to build the interpreter so it will automatically search for the libs you describe, as here:

If not, perl 5.16.4 will be published to users but not those who depend on it, then at startup, programs will fail to find

/usr/lib/perl5/5.16.2/x86_64-linux-thread-multi/CORE/libperl.so that is no longer there. ---- Perl programs don't have hard coded versions. They look in @INC: perl -e 'use P; P "%s", \@INC;' ["/home/law/bin/lib", "/usr/lib/perl5/site_perl/5.16.2/x86_64-linux-thread-multi", "/usr/lib/perl5/site_perl/5.16.2", "/usr/lib/perl5/vendor_perl/5.16.2/x86_64-linux-thread-multi", "/usr/lib/perl5/vendor_perl/5.16.2", "/usr/lib/perl5/5.16.2/x86_64-linux-thread-multi", "/usr/lib/perl5/5.16.2", "/usr/lib/perl5/site_perl/5.16.2/x86_64-linux-thread-multi", "/usr/lib/perl5/site_perl/5.16.2", "/usr/lib/perl5/site_perl", '.'] If I upgrade to 5.16.4, all of those are updated -- so the program you have that looks for libperl.so in "/usr/lib/perl5/5.16.2/x86_64-linux-thread-multi/CORE" will automatically find the new libperl for 5.16.4 because the path will be updated. You have created an issue where there was no issue. You still haven't answered why python and ruby can have upgrades but not perl. Show me a program that you think won't work that ships with the distro. If it doesn't it's a bug in the way the program was developed to hard code a path and not use Perl's standard library path. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Cristian Rodríguez wrote:

El 09/06/13 20:07, Linda Walsh escribió:

...

Perl programs don't have hard coded versions. They look in @INC:

I never said they did, executables that are dynamically linked to libperl do, however.

...

You have created an issue where there was no issue.

I asked you for an example of one that did that failed.... I have asked why the restriction on perl but not on Ruby and Python. That's 3 questions you will not or can not answer. If you can't come up with a suse product that hard codes the location of the perl library, then you've created this problem you claim exists -- but doesn't. It's the only reason you claim perl needs to be unupgradable -- unlike any other rpm including those for system script engines like python or ruby.

Nope, I have created no issue, the person inventing problems here is you.

--- Who made the change to require specific versions of perl? Not I. You are avoiding answering any question that would back up your assertions. On the contrary, I have a bug report that I can refer you to in the perl database about this exact problem -- that you claim perl isn't stable between minor releases. Their answer to that was 'not true'. If you have any evidence to backup your assertions, then please show us, because so far you've created this hypothetical situation of some app that uses the perl library, but doesn't use the perl-library path and that hard codes a specific version location for that library that fails. An example of one that doesn't fail: Gvim someone (you?) added a specific version dependency on a specific version of perl. This is both unnecessary and also illustrates the fallacy that it would break if it didn't have a hard coded version check. To the contrary -- it BREAKS because of the hard-coded version check. You are only guaranteeing that things WILL fail and more often -- whereas you can't give any examples of failures caused by the reverse stance. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org