Feature #1581

Add architecture information to software list

Added by Remi Collet about 1 year ago. Updated about 1 year ago.

Status:ClosedStart date:04/14/2012
Priority:NormalDue date:
Assignee:Guillaume Rousse% Done:

0%

Category:internal
Target version:2.2.1
For junior contributor:No

Description

In previous version, software name was "name.arch"

With 2.2.0 it is only "name"

Please, revert to previous behavior until a "stable" solution is possible

fusioninventory-agent-arch.patch Magnifier - Revert to previous behavior (743 Bytes) Remi Collet, 04/16/2012 07:49 am

History

#1 Updated by Gonéri Le Bouder about 1 year ago

  • Category set to linux

Just a detail, this is a RPM related issue.

#2 Updated by Gonéri Le Bouder about 1 year ago

Are SOFTWARES/ARCH keys avalaible in your XML output?

#3 Updated by Remi Collet about 1 year ago

No ARCH information

    <VERSIONCLIENT>FusionInventory-Agent_v2.2.0</VERSIONCLIENT>
...
    <SOFTWARES>
      <COMMENTS>A free and portable font rendering engine</COMMENTS>
      <FILESIZE>854441</FILESIZE>
      <FROM>rpm</FROM>
      <INSTALLDATE>Sun Dec 11 08:15:55 2011</INSTALLDATE>
      <NAME>freetype</NAME>
      <PUBLISHER>Fedora Project</PUBLISHER>
      <VERSION>2.4.6-4.fc16</VERSION>
    </SOFTWARES>
...
    <SOFTWARES>
      <COMMENTS>A free and portable font rendering engine</COMMENTS>
      <FILESIZE>840709</FILESIZE>
      <FROM>rpm</FROM>
      <INSTALLDATE>Sat Dec 17 08:13:05 2011</INSTALLDATE>
      <NAME>freetype</NAME>
      <PUBLISHER>Fedora Project</PUBLISHER>
      <VERSION>2.4.6-4.fc16</VERSION>
    </SOFTWARES>
...

And : 

$ rpm -qa --qf "%{name} %{version} %{arch}\n" freetype
freetype 2.4.6 x86_64
freetype 2.4.6 i686

#4 Updated by Remi Collet about 1 year ago

Patch applied in fedora RPM.

#5 Updated by Guillaume Rousse about 1 year ago

  • Tracker changed from Bug to Feature
  • Subject changed from arch regression to Add architecture information to software list
  • Assignee set to Guillaume Rousse
  • Target version set to 2.3.0

The behavior change was intentional. Let's use a technically correct solution for next feature release (2.3.0).

#6 Updated by Gonéri Le Bouder about 1 year ago

  • Category changed from linux to internal
  • Status changed from New to In Progress
  • Target version changed from 2.3.0 to 2.2.1

NAME = $name + $arch is a hack. The plan was to add a clean ARCH key to store the information, that's something that is clearly missing today.

By removing the hack we create a regression, it is not possible anymore to know the architecture of a given package at all and worst, a second package looks the same.

This bug had been opened for RPM, but we will have the same situation with MacOSX, Windows and Debian's multiarch.

I think in the 2.2.1 we must restore the previous behavior and had a SOFTWARES/ARCH key to begin the transition.
In the 2.3.0, we will be able to fix the RPM names or generalize the name format to all the multiarch OSes (Windows, Debian, MacOSX).

#7 Updated by Guillaume Rousse about 1 year ago

I clearly disagree with restoring previous behaviour, as already explained on the list: using a 'name' property to store more than the name is an hack. And what may be considered by 'practical' for some may as well be considered as 'harmful' for others.

However, an intermediate solution achievable right now for 2.2.1 is to generalize the use of 'is64bit' property already used in Windows software list.

#8 Updated by Gonéri Le Bouder about 1 year ago

SOFTWARES/IS64BIT was a bad idea because you can mix different 32 or 64 architecture (MacOSX: powerpc32 / intel32 or Debian's multiarch: AMD64, SPARC64). I believe a SOFTWARES/ARCH is the sole valid option.

#9 Updated by Guillaume Rousse about 1 year ago

I perfectly agree, but for 2.3.x branch, not for current one.

#10 Updated by Gonéri Le Bouder about 1 year ago

SOFTWARES/ARCH is harmless and could feet in a stable release to prepare the future transition. In the meanwhile I think we should acknowledge Remi path for RHEL on the 2.2.x branch.

This rise a more general topic about the status of the stable branches. During the 2.1.x lift time we added some new minor features. If we decide top stop with this policy, we must reduce the time between stable release. I would prefer myself that we focus directly on the 3.0 branch and its REST/JSON format.

#11 Updated by Guillaume Rousse about 1 year ago

Let's go for adding ARCH property in 2.2.1 then, that's quite a minor change.

#12 Updated by Guillaume Rousse about 1 year ago

I just pushed commits c63d196 and 25bf844 implementing those changes for windows, rpm and dpkg.

#13 Updated by Gonéri Le Bouder about 1 year ago

  • Status changed from In Progress to Resolved

#14 Updated by Gonéri Le Bouder about 1 year ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF