Will be fixed for digikam 2.

CC: (none) => balcaen.john

Fixed with digikam-2.0.0-0.rc.2.mga2.src.rpm

Status: NEW => RESOLVED
Resolution: (none) => FIXED

reopening for Mageia 1 since the bug is still present

Status: RESOLVED => REOPENED
Version: Cauldron => 1
Resolution: FIXED => (none)

For QA
Could you please test this package on i586.
Everything is ok on x86_64 with this update 
How to test :
install the kipi-plugins-expoblending from core/release
uninstall hugin as it's suggested by digikam package if this package was eventually installed
Try to launch expoblending & notice the error in bug report.

Install the package from core/updates_testing
Notice that you're able to launch expoblending

Proposal Advisory:

« Kipi-plugins-expoblending requires hugin to be functionnal, this package add as requires the missing package»

Assignee: bugsquad => qa-bugs

Assigned to qa-bugs

Status: REOPENED => ASSIGNED

I'm on it

CC: (none) => stormi

everything ok on i586

Please push kipi-plugins-1.9.0-3.1.mga1 to updates

Advisory :

Kipi-plugins-expoblending requires hugin to be functionnal but could be installed without it, thus being unusable. This update ensures hugin is installed too.

still needs tests on x86_64 according to policy

Keywords: validated_update => (none)

Tests OK on x86_64

CC: (none) => derekjenn

Thanks for your tests Derek, hope to see you soon on other bug reports ;)

Please push kipi-plugins-1.9.0-3.1.mga1 to updates

Advisory :

Kipi-plugins-expoblending requires hugin to be functionnal but could be
installed without it, thus being unusable. This update ensures hugin is
installed too.

Keywords: (none) => validated_update

Pushed to updates.

Status: ASSIGNED => RESOLVED
CC: (none) => boklm
Resolution: (none) => FIXED

Until bug 2317 is solved, this update cannot be installed using mgaapplet.

In order to allow this update to proceed while bug 2317 is being sorted out,
can someone from the sysadmin team copy hugin from Core Release to Core Updates
please.

The srpm is
hugin-2010.4.0-2.mga1.src.rpm

Status: RESOLVED => REOPENED
CC: (none) => davidwhodgins
Resolution: FIXED => (none)

in fact i'll push a rebuild instead.

(In reply to comment #15)
> in fact i'll push a rebuild instead.

This is the "wrong fix" as hugin have to pass QA now too...

The best way to fix this issue for Mageia 1 is to hardlink the needed rpms from /release to /updates

CC: (none) => tmb

(In reply to comment #16)
> (In reply to comment #15)
> > in fact i'll push a rebuild instead.
> 
> This is the "wrong fix" as hugin have to pass QA now too...
> 
> The best way to fix this issue for Mageia 1 is to hardlink the needed rpms from
> /release to /updates

Well i pushed it due to https://bugs.mageia.org/show_bug.cgi?id=2317.
But if we can use hardlink i'm not against it.

please test, as quickly as possible so that the update is not broken anymore in MageiaUpdate, the new hugin package in core/updates_testing, on i586 ans x86_64

Keywords: validated_update => (none)

(In reply to comment #12)
> Please push kipi-plugins-1.9.0-3.1.mga1 to updates
> 
> Advisory :
> 
> Kipi-plugins-expoblending requires hugin to be functionnal but could be
> installed without it, thus being unusable. This update ensures hugin is
> installed too.

Please note spelling mistake in Advisory text, should be - functional

(Sorry Stormi!)

CC: (none) => eeeemail

kipi-plugins-expoblending does not exist in core/updates_testing

Tested with kipi-plugins-1.9.0-3.1.mga1 from core/updates on i586.

It requires hugin-2010.4.0-2.mga1 from core/release, or the new one in updates_testing.

Once both packages installed (hugin from core/release), expoblending appears to work correctly with no errors reported.

I will do the same test on x86_64.

Is this correct or is there a newer build to test?

i586:

Also tested kipi-plugins-expoblending-1.9.0-3.1.mga1 with hugin-2010.4.0-2.1.mga1 from updates_testing

expoblending worked without any errors reported. hugin itself reported two errors/warnings, see bug 2213 but does save a panorama after clicking OK to the two warnings.

Please ignore comment 21 about hugin, after removing ~/.hugin and reinstalling the warnings are gone. Left over settings from testing autopano-sift-C

hugin-2010.4.0-2.1.mga1 from updates_testing aligns two images from hugin tutorials pages and creates a panorama without any errors.

expoblending also reports no errors

I'll carry out the same process on x86_64

Expoblending tested without errors on x86_64 with hugin-2010.4.0-2.1.mga1 from updates_testing

hugin tested without errors, created panorama as normal.

(In reply to comment #23)
> Expoblending tested without errors on x86_64 with hugin-2010.4.0-2.1.mga1 from
> updates_testing

(In reply to comment #24)
> hugin tested without errors, created panorama as normal.

Same for me.

Tested on Mageia release 1 (Official) for x86_64 ,and it's OK for me.

Nothing to report.

CC: (none) => geiger.david68210

Please push hugin to updates (the other packages already have been pushed)

Advisory :

Kipi-plugins-expoblending requires hugin to be functional but could be
installed without it, thus being unusable. This update ensures hugin is
installed too.

Please also fix the advisory for kipi-plugins-1.9.0-3.1.mga1 (typo in "functional") or let us know how to fix it ourselves.

Keywords: (none) => validated_update

As per comment 26, can someone from the sysadmin team push
hugin-2010.4.0-2.1.mga1.src.rpm
from Core Updates Testing to Core Updates please.

Advisory :
Kipi-plugins-expoblending requires hugin to be functional but could be
installed without it, thus being unusable. This update ensures hugin is
installed too.

Please also fix the advisory for kipi-plugins-1.9.0-3.1.mga1 (typo in
"functional") or let us know how to fix it ourselves.

update pushed.

Status: REOPENED => RESOLVED
CC: (none) => dmorganec
Resolution: (none) => FIXED

It is still not possible to update kipi-plugins-expoblending in MCC:

Sorry, the following package cannot be selected:

- kipi-plugins-expoblending-1.9.0-3.1.mga1.i586 (due to conflicts with hugin-2010.4.0-2.1.mga1.i586)

Priority: Normal => High
Status: RESOLVED => REOPENED
CC: (none) => g.sprik
Resolution: FIXED => (none)

Gerald, can you please run
urpmi --debug --auto-select 2>&1 | tee /tmp/urpmi-log.txt
and then attach /tmp/urpmi-log.txt to this bug report.

Created attachment 738 [details]
Output of urpmi --debug --auto-select 2>&1 | tee /tmp/urpmi-log.txt (comment #30)

rpm -qa|grep -e kipi-plugins-expoblending  -e hugin
kipi-plugins-expoblending-1.9.0-3.1.mga1
hugin-2010.4.0-2.1.mga1

I believe This is tied into bug 2317, and that the error was
from mgaapplet trying to install the update.

Did you answer Y to the proceed question?  If not, please do so.

In order for mgaapplet (as it currently works) to install the update,
the packages ...
  enblend                        4.0          1.mga1        i586    
  libboost_regex1.44.0           1.44.0       6.mga1        i586    
  libboost_signals1.44.0         1.44.0       6.mga1        i586    
  libboost_system1.44.0          1.44.0       6.mga1        i586    
  libboost_thread1.44.0          1.44.0       6.mga1        i586    
  libglew1.5                     1.5.8        2.mga1        i586    
  libpano13-tools                2.9.17       2.mga1        i586    
  libpano13_0                    2.9.17       2.mga1        i586    
  libplotutils2                  2.6          7.mga1        i586    
  libwxgtkglu2.8                 2.8.11       4.mga1        i586    
  make                           3.82         4.mga1        i586    
  perl-Image-ExifTool            8.500.0      1.mga1        noarch 
will have to be copied to Core Release Updates.

(In reply to comment #32)

Dave, thanks for your reply.

> I believe This is tied into bug 2317, and that the error was
> from mgaapplet trying to install the update.

From mgaapplet or from rpmdrake?
This bug is not only in Mageia Update but also in MCC Software management.

> Did you answer Y to the proceed question?  If not, please do so.

No I didn't. I can do so, but then urpmi will install all dependency packages nicely. I checked this by urpmi --test --auto-select. 

After that I would no longer be able to reproduce this bug in MCC or Mageia Update (and to test the following solution).

> In order for mgaapplet (as it currently works) to install the update,
> the packages ...
>   enblend                        4.0          1.mga1        i586    
>   libboost_regex1.44.0           1.44.0       6.mga1        i586    
>   libboost_signals1.44.0         1.44.0       6.mga1        i586    
>   libboost_system1.44.0          1.44.0       6.mga1        i586    
>   libboost_thread1.44.0          1.44.0       6.mga1        i586    
>   libglew1.5                     1.5.8        2.mga1        i586    
>   libpano13-tools                2.9.17       2.mga1        i586    
>   libpano13_0                    2.9.17       2.mga1        i586    
>   libplotutils2                  2.6          7.mga1        i586    
>   libwxgtkglu2.8                 2.8.11       4.mga1        i586    
>   make                           3.82         4.mga1        i586    
>   perl-Image-ExifTool            8.500.0      1.mga1        noarch 
> will have to be copied to Core Release Updates.

Gerald, we have lots of examples of this problem now, so you can go ahead,
or you can wait to test the fix, as you prefer.

Thank you for your report though, as it's made the scope of bug 2317
clearer to me.

When adding an rpm, as an update, that did not exist in Mageia release,
all dependencies of the update have to be treated as new dependencies.

In this case kipi-plugins-expoblending depends on hugin (a truly
added dependency), but hugin depends on enblend, which is only in
core release.

Created attachment 742 [details]
Possible patch to fix the update.

Gerald, can you try the patch, either by applying this patch to
/usr/sbin/MageiaUpdate, or by downloading a patched copy from
http://www.ody.ca/~dwhodgins/MageiaUpdate

I'm not sure if the change will fix it or not, and recreating the situation
you have, would require me to reinstall Mandriva first.

(In reply to comment #35)
 
> Gerald, can you try the patch, either by applying this patch to
> /usr/sbin/MageiaUpdate, or by downloading a patched copy from
> http://www.ody.ca/~dwhodgins/MageiaUpdate

I tried the patched copy from your website.

> I'm not sure if the change will fix it or not, and recreating the situation
> you have, would require me to reinstall Mandriva first.

With your patched copy of MageiaUpdate in /usr/sbin it is now possible to install the update of kipi-plugins-expoblending and all dependencies in MCC.
I have no understanding of perl scripts, but I can confirm that your patch works on my system!

Thanks for testing.  I'll try and get it pushed to core Updates Testing,
for more widespread testing, and wait till it's pushed to updates, before
closing this bug report.

Dave, I am very sorry, but I forgot something in comment 36.

Immediately after the installation of kipi-plugin-expoblending and all dependencies, I got a new list of 3 software package updates (mlt, libmlt4, libmlt++3), with this warning: "Notice: This package is a potential candidate for an update. It is not supported by Mageia. It may break your system."

These 3 package updates are in Core-backports-testing (distrib 9) which is NOT enabled in my list of media sources. These updates should not show up in the list of software package updates.

I am afraid that some users may not read the warning, but click on "Update" again.

In my opinion MageiaUpdate shouldn't install packages from sources that are not enabled in the list of media sources.

Ouch!  Agreed.  I'll dig through rpmdrake some more, and see if I can figure
out how to get this to work properly.

I'm not a perl coder, but can usually figure out what it's doing,
eventually.

(In reply to comment #39)
> Ouch!  Agreed.  I'll dig through rpmdrake some more, and see if I can figure
> out how to get this to work properly.

See https://bugs.mageia.org/show_bug.cgi?id=2317#c0

CC: (none) => pterjan

Will copying enblend to Core Updates allow to close this bug ?

Once it's copied, and Gerald updates (using the original MageiaUpdate),
to confirm there are no other dependencies needed, then we can close this one.

according to comment #36 Gerald already updated the package, isn't it ?

Sysadmins, please link enblend from Core Release to Core Updates. 

The expoblending and hugin packages were already pushed but enblend is a missing dependency that blocks the update in MageiaUpdate.

Keywords: (none) => validated_update

(In reply to comment #43)
> according to comment #36 Gerald already updated the package, isn't it ?

Ah. Yes.  I'll close the bug report when enblend shows up in Core Updates.

I just test again in a vm ( DVD x86_64 choosing kde as desktop) & there is more missing packages.... :/ 

[root@localhost mikala]# sudo urpmi --media "Core Updates" --auto-select --debug
getting lock on urpmi
parsing: /etc/urpmi/mediacfg.d/Official-1-x86_64
examen de la liste de synthèse [/var/lib/urpmi/Core Updates/synthesis.hdlist.cz]
getting exclusive lock on rpm
opening rpmdb (root=, write=)
auto-select: adding kipi-plugins-expoblending-1.9.0-3.1.mga1.x86_64 replacing kipi-plugins-expoblending-1.9.0-3.mga1.x86_64
selecting kipi-plugins-expoblending-1.9.0-3.1.mga1.x86_64
set_rejected: kipi-plugins-expoblending-1.9.0-3.mga1.x86_64
requiring hugin for kipi-plugins-expoblending-1.9.0-3.1.mga1.x86_64
selecting hugin-2010.4.0-2.1.mga1.x86_64
requiring enblend[>= 3.2],libGLEW.so.1.5()(64bit),libboost_regex.so.1.44.0()(64bit),libboost_signals.so.1.44.0()(64bit),libboost_system.so.1.44.0()(64bit),libboost_thread.so.1.44.0()(64bit),libpano13-tools[>= 2.9.17],libpano13.so.2()(64bit),libwx_baseu-2.8.so.0()(64bit),libwx_baseu_net-2.8.so.0()(64bit),libwx_gtk2u_adv-2.8.so.0()(64bit),libwx_gtk2u_core-2.8.so.0()(64bit),libwx_gtk2u_gl-2.8.so.0()(64bit),libwx_gtk2u_html-2.8.so.0()(64bit),libwx_gtk2u_xrc-2.8.so.0()(64bit),perl-Image-ExifTool for hugin-2010.4.0-2.1.mga1.x86_64
no packages match libwx_baseu_net-2.8.so.0()(64bit) (it is either in skip.list or already rejected)
unselecting hugin-2010.4.0-2.1.mga1.x86_64
unselecting kipi-plugins-expoblending-1.9.0-3.1.mga1.x86_64
adding a reason to already rejected package hugin-2010.4.0-2.1.mga1.x86_64: unsatisfied libwx_baseu_net-2.8.so.0()(64bit)
Le paquetage demandé ne peut pas être installé :
hugin-2010.4.0-2.1.mga1.x86_64 (car libwx_baseu_net-2.8.so.0()(64bit) est non satisfait)
Désirez-vous tout de même continuer ? (O/n)
So we also need to move lib(64)wxgtku2.8 and wxgtk2.8 for enblend...
But it's still not enough :
adding a reason to already rejected package hugin-2010.4.0-2.1.mga1.x86_64: unsatisfied libboost_system.so.1.44.0()(64bit)
adding a reason to already rejected package hugin-2010.4.0-2.1.mga1.x86_64: unsatisfied libpano13.so.2()(64bit)
adding a reason to already rejected package hugin-2010.4.0-2.1.mga1.x86_64: unsatisfied libboost_signals.so.1.44.0()(64bit)
adding a reason to already rejected package hugin-2010.4.0-2.1.mga1.x86_64: unsatisfied libpano13-tools[>= 2.9.17]
adding a reason to already rejected package hugin-2010.4.0-2.1.mga1.x86_64: unsatisfied libboost_thread.so.1.44.0()(64bit)
adding a reason to already rejected package hugin-2010.4.0-2.1.mga1.x86_64: unsatisfied libGLEW.so.1.5()(64bit)
adding a reason to already rejected package hugin-2010.4.0-2.1.mga1.x86_64: unsatisfied perl-Image-ExifTool
adding a reason to already rejected package hugin-2010.4.0-2.1.mga1.x86_64: unsatisfied enblend[>= 3.2]
adding a reason to already rejected package hugin-2010.4.0-2.1.mga1.x86_64: unsatisfied libwx_gtk2u_gl-2.8.so.0()(64bit)
adding a reason to already rejected package hugin-2010.4.0-2.1.mga1.x86_64: unsatisfied libboost_regex.so.1.44.0()(64bit

in summary we need to move lib(64)boost_regex1.44.0  lib(64)wxgtkglu2.8  endblend  lib(64)plotutils2  perl-Image-ExifTool lib(64)glew1.5 lib(64)boost_thread1.44.0 libpano13-tools lib(64)boost_signals1.44.0 lib(64)pano13_0 lib(64)boost_system1.44.0 wxgtk2.8 lib(64)wxgtku2.8

Please note that it's going to work only for the default KDE4 install from dvd, i did not try the upgrade from a live KDE cd (or from a Gnome iso/dvd but in that case it should have been a manual installation so hugin/enblend might be installed as suggests).

The only word that comes to my mind is "arrrgh" !

To sysadmins: according to comment #46, please link 

lib(64)boost_regex1.44.0  lib(64)wxgtkglu2.8 
endblend  lib(64)plotutils2  perl-Image-ExifTool lib(64)glew1.5
lib(64)boost_thread1.44.0 libpano13-tools lib(64)boost_signals1.44.0
lib(64)pano13_0 lib(64)boost_system1.44.0 wxgtk2.8 lib(64)wxgtku2.8 

From Core Release to Core Updates

Or convince anyone to fix MageiaUpdate :)

Note that enblend has not yet been linked to Core Updates.

(In reply to comment #49)
> Note that enblend has not yet been linked to Core Updates.

Yep, i simply past all the required packages to have it working.

John, was this a fresh install or an upgrade from Mandriva?

(In reply to comment #51)
> John, was this a fresh install or an upgrade from Mandriva?
Fresh install of the DVD x86_64 in a vm.

Sysadmins.  It's been a week since the request to link enblend from core
release to core updates, and four days since the request to add a bunch
more.

Is the procedure to link packages working?

i am on it now.

is ok now linking have been done.


Tell me if any pb i will fix .

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED

I see the packages have been linked to updates testing now.

Thank you very much sysadmins.  When checking, I noticed a couple of the
packages also have tainted versions, and they should also be linked
from Tainted Release to Tainted Updates.

libpano13-tools
Same with lib(64)pano13_0

Can someone from the sysadmin team link these two as well?

Thanks.

reopening

Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

linked done.

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED

Hugin is missing make in updates. It gave an error message on a fresh installation whilst doing the updates before the reboot.

Some requested packages cannot be installed
hugin-2010.4.0-2.1.mga1.x86_64 (due to unsatisfied make)


Sysadmin please link 'make' from core/release to core/updates

Thankyou!

Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

Here there's something wrong because hugin should not requires « make » package (or any devel package) .
Could you please give the ouput of the urpmi --debug --media "Core Updates Testing" kipi-plugins-expoblending ?

Sophie shows make in deps for hugin.
http://sophie.zarb.org/distrib/Mageia/1/x86_64/media/core-updates/by-pkgid/370c59f969541d7dd914891089427537/deps

I'm not able to perform the urpmi on the machine I had just installed because it is currently upgrading to cauldron. kipi-plugins-expoblending is no longer in updates_testing it is in updates.

Arrgh.  Looks like a wrong requires to me.  The make package does not provide
any libraries, and strings /usr/bin/hugin|grep make doesn't look to me like
it's calling the actual make command.

It does have ...
$ ldd -r /usr/bin/hugin|grep make
        libmakefilelib.so.0.0 => /usr/lib/hugin/libmakefilelib.so.0.0 (0xb618f000)

[dave@hodgins ~]$ urpmq --requires hugin|wc -l
--requires behaviour changed, use --requires-recursive to get the old behaviour
126
[dave@hodgins ~]$ urpmq --requires hugin|sort -u|wc -l
--requires behaviour changed, use --requires-recursive to get the old behaviour
62

$ urpmq --requires-recursive hugin|sort -u|wc -l
329

Should we link all 329 packages?  That's the only way to guarantee bug 2317
won't show up on this one again.

Created attachment 845 [details]
List of packages to be linked from Core Release to Core Updates.

The attached list includes all 36 packages showen by
urpmq --requires-recursive hugin, that are not included in
urpmq --requires-recursive basesystem-minimal.

Please link all 36 packages from Core Release, to Core Updates.

Sorry, that's 37 packages.  I didn't notice the choice for
libfreeglut3 or libmesaglut3, both of which should be linked too.

Hum in fact there's indeed a specific require to make & a look to hugin readme explain why :

3. DEPENDENCIES

The following external programs are REQUIRED:

1. enblend 3.2 or later, this includes the enfuse tool
2. exiftool from the Image::ExifTool perl module
3. gnu make is required for stitching

Created attachment 854 [details]
Script to show new requires.

Could someone from the sysadmin team link the 37 packages listed in
attachment 845 [details] from Core Release to Core Updates.

The attached script is what I used to find the 37 packages needed for hugin.
It gets the list of dependencies using urpmi --requires-recursive.
Excludes any packages installed by base-system-minimal.
Excludes any packages already in Core Updates.

The script will need modifications for Nonfree, and Tainted, after which
I'll be using it for all added dependencies, to determine the link requirements.

I get different results with a slightly different script (inspired by both the commands I sent to the qa-discuss ML and your script):

Rather than working directly on the hugin package, I compared the kipi-plugins-expoblending package from Core Release to that in Core Updates. The main difference is that it won't list dependencies for hugin that are already dependencies for kipi-plugins-expoblending (which is the package concerned by bug #2317). 
The other main change is the --no-suggests option to urpmq, otherwise it lists recursively all suggests, giving the fake impression that some packages are required. Indeed, urpmq --requires-recursive kipi-plugins-expoblending-1.9.0-3.mga1 (the version from Core Release) lists hugin, because kipi-plugins-expoblending requires kipi-plugins and kipi-plugins suggests hugin.

[samuel@localhost mga_packages]$ cat checknewdeps.sh
#!/bin/sh
if [ -z $2 ]
then
        echo "Syntax: $0 package_from_release package_from_updates"
        exit 1
fi
mkdir -p ~/tmp/finddeps
cd ~/tmp/finddeps
urpmq --requires-recursive --no-suggests $1 | tr '|' '\n' | sort > old.txt
urpmq --requires-recursive --no-suggests $2 | tr '|' '\n' | sort > new.txt
urpmq --list --media Updates --excludemedia Testing > updates.txt
urpmq --requires-recursive --no-suggests basesystem-minimal | tr '|' '\n' > basesystem.txt
sort -u old.txt updates.txt basesystem.txt > already_available.txt
comm -23 new.txt already_available.txt

[samuel@localhost mga_packages]$ ./checknewdeps.sh kipi-plugins-expoblending-1.9.0-3.mga1 kipi-plugins-expoblending-1.9.0-3.1.mga1
desktop-file-utils
libdri-drivers
libdrm2
libdrm-common
libdrm_intel1
libdrm_radeon1
libfontenc1
libfreeglut3
libicu44
libmesagl1
libmesaglu1
libmesaglut3
libxaw7
libxmu6
libxpm4
libxt6
libxxf86vm1
make
mkfontdir
mkfontscale
x11-data-bitmaps
x11-font-daewoo-misc
x11-font-isas-misc
x11-font-jis-misc

Dave: do you agree with this new list ?

Both of your changes seem correct to me.  And in future, it will simplify
checking for missing dependencies if we check with the package that is
having dependencies added, where there are multiple new dependencies.

Go ahead with the new list.

Run 64 bit:

$ ./checknewdeps.sh kipi-plugins-expoblending-1.9.0-3.mga1 kipi-plugins-expoblending-1.9.0-3.1.mga1
desktop-file-utils
lib64dri-drivers
lib64drm2
lib64drm_intel1
lib64drm_radeon1
lib64fontenc1
lib64freeglut3
lib64icu44
lib64mesagl1
lib64mesaglu1
lib64mesaglut3
lib64xaw7
lib64xmu6
lib64xpm4
lib64xt6
lib64xxf86vm1
libdrm-common
make
mkfontdir
mkfontscale
x11-data-bitmaps
x11-font-daewoo-misc
x11-font-isas-misc
x11-font-jis-misc

To sysadmins: please link the packages listed in comment #67 for i586 and comment #69 for x86_64 from Release to Updates

I wonder why libdrm-common is not listed on x86_64

(In reply to comment #71)
> I wonder why libdrm-common is not listed on x86_64

It is.

But I dont see the point of linking drm and x11 stuff, as they all are installed if xorg server is installed.

by a quick look on that list, I guess only make is the only one needing linking

(In reply to comment #72)
> (In reply to comment #71)
> > I wonder why libdrm-common is not listed on x86_64
> 
> It is.
> 
> But I dont see the point of linking drm and x11 stuff, as they all are
> installed if xorg server is installed.
> 

That's right: as the problem we want to workaround concerns MageiaUpdate, we can safely ignore all packages already required by MageiaUpdate's package, recursively.

We'll adapt the "find new deps" script in this regard.

After removing deps from x11-server and MageiaUpdate, now the list is, for i586:

libdri-drivers
libdrm_intel1
libdrm_radeon1
libfreeglut3|libmesaglut3
libmesagl1
libmesaglu1
libxxf86vm1
make

There are still drm libs, etc., but unless there is another package whose presence in guaranteed on the user system and that should be taken into account in our script, we need to link them as they could prevent an update via MageiaUpdate.

x86_64

lib64dri-drivers
lib64drm_intel1
lib64drm_radeon1
lib64freeglut3|lib64mesaglut3
lib64mesagl1
lib64mesaglu1
lib64xxf86vm1
make

(In reply to comment #74)
> 
> There are still drm libs, etc., but unless there is another package whose
> presence in guaranteed on the user system and that should be taken into account
> in our script, we need to link them as they could prevent an update via
> MageiaUpdate.

the drm stuff is used by every display driver as a link between kernel drm and userspace drivers, so X wont start without drm available.

(In reply to comment #76)
> (In reply to comment #74)
> > 
> > There are still drm libs, etc., but unless there is another package whose
> > presence in guaranteed on the user system and that should be taken into account
> > in our script, we need to link them as they could prevent an update via
> > MageiaUpdate.
> 
> the drm stuff is used by every display driver as a link between kernel drm and
> userspace drivers, so X wont start without drm available.

I looked at x11-driver-video-ati: it requires libdrm_radeon1 of course, but not libdrm_intel1. So I guess we can find systems with only the first installed. Unless there's a higher level package that is always installed and pulls them ? libdri-drivers requires them, but is it always installed ?

What we need is the name of a package that is always installed along with X and that requires all this stuff, so that we can exclude it in our script.

We always install all drm drivers by default in order to support changing display adapter without need of installing additional rpms.

for xorg install rpmsrate selects x11-driver-video wich pulls in all x11-driver-video-* wich pulls in all the drm packages

ok, thanks. 

Now that makes the situation clear: we must decide whether we support updates for every users or only for those who haven't made a very minimal install or have removed packages after the installation.

Either we make sure the updates work through MageiaUpdate for all users and then we have to link them because they might be not present on the system, or we consider that the vast majority has them on the system, and those who have removed them are capable to workaround the "this update cannot be installed" bug.

Well, IMHO if they uninstall packages that a normal user would not (such as x11-driver-video), they are probably urpmi users anyway. 

So I would expect them to cope with it, and only think of MageiaUpdate users that does not mess up default install.

If not we will soon have linked all of core to updates tree.

I have removed anything provided by x11-driver-video from our depcheck script results.

We are left with the dependencies below which require linking.

libdri-drivers
libfreeglut3|libmesaglut3
libmesagl1
libmesaglu1
libxxf86vm1
make

This proposes a system installed with basesystem-minimal, rpmdrake, x11-server and x11-driver-video.

Is this more realistic?

As rpmdrake suggests libdri-drivers, libxxf86vm1 and mesa I think we can remove those too.

That leaves just 'make' requiring linking from core/release to core/updates please sysadmin!

Sorry. I am wrong.

libfreeglut3|libmesaglut3
libmesaglu1

Also need linking.

(In reply to comment #83)
> Sorry. I am wrong.
> 
> libfreeglut3|libmesaglut3
> libmesaglu1
> 
> Also need linking.

Hugin was built with mesaglut for Mageia1 (freeglut has been used as BR only in cauldron  since Mageia is switching from mesaglut to freeglut bug 2412 )

You may only ask a link for libmesaglut3
(libfreeglut3 may conflict with libmesaglut3 if you ask for both of them)

CC: (none) => philippedidier

(In reply to comment #84)
> (In reply to comment #83)
> > Sorry. I am wrong.
> > 
> > libfreeglut3|libmesaglut3
> > libmesaglu1
> > 
> > Also need linking.
> 
> Hugin was built with mesaglut for Mageia1 (freeglut has been used as BR only in
> cauldron  since Mageia is switching from mesaglut to freeglut bug 2412 )
> 
> You may only ask a link for libmesaglut3
> (libfreeglut3 may conflict with libmesaglut3 if you ask for both of them)

Linking them both from Release to Updates will not raise any conflict. It's just a matter of providing them in the Updates media so that they are available if needed.

I understand well that giving the links will not raise by itself any conflict...

But : freeglut is not needed by anything in Mageia1...
it has just been imported in the repo to prepare a future switch,
And worse : freeglut and mesaglut may not be installed side by side. 

More than 30 rpms in Mageia1 have been built with mesaglut

If the choice is given to install freeglut it will obsolete mesaglut and that may ask to uninstall rpms depending on mesaglut... that would be a real mess !!!!

You may believe that I really know what is the conflict problem between those 2 libraries :
- 3 years ago, when using Mandriva, I had to struggle  when I tried to compile a program that needed freeglut instead of mesaglut (I had to use some workarounds to install freeglut instead of mesaglut without uninstalling other programs) 

- I have contributed to get rid of mesaglut in Mageia cauldron and, finally, only since october 2nd, someone can install freeglut in an up to date computer running cauldron (nothing depends on mesaglut anymore)

I am perhaps too much cautious but I'm afraid that giving a link that is not useful may bring secondary problems ...

I think you misunderstand the meaning of that "link". We will just copy the freeglut package that is already present, available, and installable from Core Release to Core Updates. It will not change the dependencies among packages in any way, so most users just won't notice that it's available in Core Updates, and won't install it as their system chose mesaglut.

However, as hugin requires either mesaglut or freeglut, and people may have chosen freeglut in the past instead of mesaglut, we have to provide both mesaglut and freeglut in Updates media to workaround bug #2317

>people may have chosen freeglut in the past instead of mesaglut

Oh , I'm silly !
I never thought that someone could have already installed freeglut, even if it is available... as the BR of all the srpms depending on a glut library is always clearly mesaglut-devel or libmesaglut-devel or mesa-common-devel... 
I really believed that freeglut would never have been installed as a dependency on any computer running Mageia1...

Actually, the require of hugin is simply "libglut.so.3", which leaves a choice: it is provided by the 2 packages, both freeglut and mesaglut, (and that's the reason of the conflict between them !)

Hope this may no bring too much trouble !


Nevertheless I prefer the risk to say something, even if I'm told that it was useless, (no shame for this), than to cowardly prevent from saying something which would be indeed useful... (that would be stupid)

So that the last comment contains the list of packages to link, here it is:

libfreeglut3
libmesaglut3
libmesaglu1
make

Linking done.

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED