Why noarch packages are available "only" on 32(main, contrib) repositories?

adelson.oliveira · January 27, 2018, 1:39am

That is it,

Some “noarch” packages seems to be found only(?) at main32, contrib32 repos. Why not at main, contrib (x86_64) repos?

Thanks

mandian · January 27, 2018, 12:32pm

Please could you make some examples?

adelson.oliveira · January 27, 2018, 3:31pm

Hi Mandian,

I am considering installing scilab 6.0 from your personal repositories. Thus I’ve tried,

$urpmi --test --debug scilab <output.txt 2>&1

with your repository “on”.

From the list of changes in the system, I have selected examples of some noarch packages from x86_64 and 32 contrib repos:

(mídia "contrib (Einsteinium3.0-5)")
 jeuclid-core                   3.1.4        5             omv   2015.0 noarch
 laf-plugin                     1.0          1             omv   2015.0 noarch
 skinlf                         6.7          0.0.7         omv   2015.0 noarch
(mídia "contrib32 (Einsteinium3.0-7)")
 flexdock                       1.2.4        2             omv   2015.0 noarch
 javahelp2                      2.0.05       18            omv   2015.0 noarch
 jgraphx                        2.2.0.2      3             omv   2015.0 noarch
 jrosetta

mandian · January 29, 2018, 6:50pm

This is bad idea unless you use a test environment. Actually I haven’t the time to follow my personal repository and there are some inconsistency with official repository so I discourage you to use for a everyday working machine. Its propose is for tests or my personal needs.

By default if a noarch packages is picked from x86_64 repository, if enabled. I think the is not difference for a noarch repo if it comes from x86_64 repository or from i586 one. Maybe it is just because it is required by a x86_&4 package or by a i586/noarch package.

BTW octave from my personal repo is working now, except for a bug with some colors in plots, maybe the culprit is gnuplot.

ben79 · January 29, 2018, 9:01pm

To my knowledge most noarch packages are in both i586 and x86_64 repos. I am reasonably certain that is the intention of our developers.

All your examples are from contrib repos which are community maintained. It is known that in terms of maintenance contrib repos are in a poor state currently.

So Community get busy and get contrib repo sorted.

adelson.oliveira · January 29, 2018, 11:38pm

Hi Ben79,

I’ve choose the contrib and contrib 32 examples just because there were just a few packages there.

There are examples in Main and Main32 too. Here is the list of a few examples in Main and Main32,

(mídia "main (Einsteinium3.0-1)")
 antlr-tool                     2.7.7        32            omv   2015.0 noarch
 antlr32-java                   3.2          5.2           omv   2015.0 noarch
 apache-commons-codec           1.10         1.2           omv   2015.0 noarch
 apache-commons-compress        1.10         1             omv   2015.0 noarch
 avalon-framework               4.3          11.2          omv   2015.0 noarch
 avalon-logkit                  2.1          17.2          omv   2015.0 noarch
 bea-stax                       1.2.0        9.2           omv   2015.0 noarch
 geronimo-jms                   1.1.1        17.1          omv   2015.0 noarch
 hawtjni-runtime                1.10         3.2           omv   2015.0 noarch
 icu4j                          54.1.1       4             omv   2015.0 noarch

(mídia "Main32 (Einsteinium3.0-3)")
 apache-commons-io              2.4          10.1          omv   2015.0 noarch
 apache-commons-logging         1.1.3        7.3           omv   2015.0 noarch
 bea-stax-api                   1.2.0        9.2           omv   2015.0 noarch
 ecj                            4.4.0        1             omv   2015.0 noarch
 jai-imageio-core               1.2          0.13.2010021> omv   2015.0 noarch
 jakarta-commons-httpclient     3.1          20.2          omv   2015.0 noarch
 jansi                          1.11         6.2           omv   2015.0 noarch
 javamail                       1.5.0        6.1           omv   2015.0 noarch
 javassist                      3.18.1       2.2           omv   2015.0 noarch
 jnr-ffi                        2.0.6        1.1           omv   2015.0 noarch

adelson.oliveira · January 29, 2018, 11:46pm

Hi Mandian,
A virtual machine usually requires a reserved space for its installation and, when on, it demands memory resources as well. It is then a trade off between safety and saving basic computer resources in a limited machine.

I wonder why some java packages in OMV official repos are outdated. If they were up to date, probably your version of scilab 6.0 and maybe the binary from scilab’s home would work, is it right?

ben79 · January 29, 2018, 11:48pm

Then you need to ask developers. QA has no control over repositories. So I’m moving this thread to Cooker.

adelson.oliveira · January 29, 2018, 11:52pm

Ok

ben79 · January 30, 2018, 12:02am

What are you basing this on? I’m doing a quick check by looking in the actual repositories and so far I’m finding the ones you have listed in Main32 are also in Main release. Then I checked the other way and same thing. To determine something like this you actually have to look in each repository. Commands that list noarch packages arbitrarily pick one or the other (i586 or x86_64) for reasons known only to some urpmi/Perl developer from the past. Probably goes all the way back to Mandrake.

adelson.oliveira · January 30, 2018, 12:07am

Then, I could just have no 32 bits repo configured. This information is some of what I would like to know with this post.

Thanks

ben79 · January 30, 2018, 12:16am

Yes, and we have been suggesting to users for a long time to not enable i586 repos in x86_64 unless you have a specific need. Like installing a 3rd party package and then when you are done disable them again. drakrpm-edit-media makes this super easy.

And users should keep in mind to be wary of anything that is only available in 32-bit as the developers for that package are seriously out of date. 64-bit has been around in pc’s since 2003 and has been in use since the 1970’s. 15 years is a very long time for computer technology.

Edit: And I moved this back to QA where it was originally posted. Guess I was a little to quick on that move.

adelson.oliveira · January 30, 2018, 12:35am

Removed 32 bit repos. Installation is still possible.

TPG · January 30, 2018, 8:32am

This is normal situatuon.

mandian · January 30, 2018, 6:21pm

Updating all java packages is a big task and I hope it will be done in time for Lx4.0. I use some more update java packages in my own repository for my own needs and I haven’t had the time to push on official one because some of them can potentially break most java packages actually in repository (and I know some of them does). Some of this dangerous packages are required as dependencies by the scialb package from my and it is because I discourage you to use it in a production environment. I am trying to build a scilab package without these updated dependencies on cooker, then I will need some testers …

The solution is to update all java packages but, as stated before, it requires a lot of time and man power, of course.

mandian · January 30, 2018, 8:23pm

@TPG: It’s like I can’t make a New Project on ABF and publish in cooker instead of openmandriva_personal. It this right?

adelson.oliveira · January 30, 2018, 11:49pm

Things are changing in my daily work and sooner than I imagined before I’ll need to work on scilab more often. Isn’t there anything I could do to help building scilab to OMV LX 3.0.3?

mandian · January 31, 2018, 6:43pm

Actually I think no. I updated most specs on ghihur repo but I need to know how to build new packages in ABF for cooker (I can build already existing packages but the one I create are published in openmandirva_perrsonal insted of cooker repository). In this way I will got a real list of all mandatory packages. Then a developer will be needed to build scilab for Lx3.0. Then is should be tested especially three point:

none java libraries is missing
plot are showed well
is this patch really working (I suspect it can cause wrong results)

adelson.oliveira · January 31, 2018, 11:17pm

I guess it will not cause wrong results. Using this patch I would expect right results or no results at all since it seems to replace one “driver” routine by another.