This issue was asked by @jeromecoutant.

Some vendors might have their own package index. Ex: Let's name https://www.keil.com/pack/index.pidx as Keil.pidx. It contains all known public packs. But ST might have their own package index, let's say ST.pidx.

While Keil.pidx contains ARM.CMSIS and hundreds of other packs, it might not contain an ST-only pack e.g. STM.Pack. Whereas ST.pidx contains STM.Pack, it won't list ARM.CMSIS in it.

Looks like cpackget does not take into account the local packs:

frq09468@LMECWL0888 MINGW64 /c/Packs
$ cpackget pack list
I: Using pack root: "c:\CMSIS_PACKS"
I: Listing installed packs
I: ARM.CMSIS-Driver.2.6.1
I: ARM.CMSIS.5.7.0
I: ARM.CMSIS.5.8.0
I: ARM.mbedTLS.1.7.0
I: ARM.PSA.1.0.0
I: Keil.ARM_Compiler.1.6.3
I: Keil.MDK-Middleware.7.12.0
I: Keil.MDK-Middleware.7.13.0
I: Keil.NUCLEO-L552ZE-Q_BSP.1.2.0
I: Keil.STM32F4xx_DFP.2.15.0
I: Keil.STM32H7xx_DFP.2.8.0
I: Keil.STM32L4xx_DFP.2.6.1
I: Keil.STM32L552E-EV_BSP.1.1.0
I: Keil.STM32L562E-DK_BSP.1.3.0
I: Keil.STM32L5xx_DFP.1.4.0
I: Keil.STM32L5xx_TFM-PF.1.1.0
I: Keil.STM32NUCLEO_BSP.1.8.0
I: Keil.STM32U5xx_DFP.1.1.0
I: STMicroelectronics.board_resources_B-U585I-IOT02A.0.0.1
I: STMicroelectronics.Example_HAL_GPIO_Toggle.0.0.1-alpha1
I: STMicroelectronics.STM32U5xx_DFP.0.1.0-alpha1
I: STMicroelectronics.STM32U5xx_Drivers.0.0.1-alpha1
I: STMicroelectronics.STM32U5xx_Drivers.0.1.0-alpha1

while:
$ csolution list packs
ARM::[email protected]
ARM::[email protected]
ARM::[email protected]
ARM::[email protected]
ARM::[email protected]
Keil::[email protected]
Keil::[email protected]
Keil::[email protected]
Keil::[email protected]
Keil::[email protected]
Keil::[email protected]
Keil::[email protected]
Keil::[email protected]
Keil::[email protected]
Keil::[email protected]
Keil::[email protected]
Keil::[email protected]
Keil::[email protected]
Keil::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
fred-r::[email protected]
fred-r::[email protected]
fred-r::[email protected]
fred-r::[email protected]
fred-r::[email protected]

Indeed:

<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<index schemaVersion="1.1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xs:noNamespaceSchemaLocation="PackIndex.xsd">

  <vendor>local repository</vendor>

  <url>file://localhost/C:/CMSIS_PACKS</url>

  <timestamp>2022-03-15T15:50:29</timestamp>

  <pindex>
    <pdsc name="lps22hh" url="file://localhost/C:/Cube20/infra/Firmware/boards/parts/lps22hh/" vendor="STMicroelectronics" version="0.0.1"/>
    <pdsc name="services" url="file://localhost/C:/Cube20/infra/Firmware/boards/services/" vendor="STMicroelectronics" version="0.0.2"/>
    <pdsc name="STM32_SBSFU_UserApplication" url="file://localhost/C:/R-CUBE-SBSFU/packages/STM32_SBSFU_UserApplication/" vendor="fred-r" version="0.0.2-PoC0"/>
    <pdsc name="common_examples" url="file://localhost/C:/Cube20/infra/Firmware/examples/common/" vendor="STMicroelectronics" version="0.0.3"/>
    <pdsc name="HAL_CRC_UserDefinedPolynomial_example" url="file://localhost/C:/Cube20/infra/Firmware/examples/HAL/CRC/CRC_UserDefinedPolynomial/" vendor="STMicroelectronics" version="0.1.0"/>
    <pdsc name="HAL_TIM_PWMOutput_2TIM" url="file://localhost/C:/Cube20/infra/Firmware/examples/HAL/TIM/TIM_PWMOutput_2TIM//" vendor="STMicroelectronics" version="0.1.0"/>
    <pdsc name="board_resources_STM32L562E-DK" url="file://localhost/C:/Cube20/infra/Firmware/boards/STM32L562E-DK/" vendor="STMicroelectronics" version="0.0.14"/>
    <pdsc name="STM32L5xx_DFP" url="file://localhost/C:/Cube20/infra/Firmware/cmsis/Device/ST/STM32L5xx/" vendor="STMicroelectronics" version="0.0.14"/>
    <pdsc name="STM32_Bootloader" url="file://localhost/C:/R-CUBE-SBSFU/packages/STM32_Bootloader/" vendor="fred-r" version="0.0.7-PoC0"/>
    <pdsc name="STM32_Cryptolib" url="file://localhost/C:/R-CUBE-SBSFU/packages/STM32_Cryptolib/" vendor="fred-r" version="0.0.2-PoC"/>
    <pdsc name="STM32F4xx_DFP" url="file://localhost/C:/silent_mx_generator/Pack/STM32F4xx_DFP_silent_mx/" vendor="Keil" version="2.16.1"/>
    <pdsc name="STM32_Secure_Engine" url="file://localhost/C:/R-CUBE-SBSFU/packages/STM32_Secure_Engine/" vendor="fred-r" version="0.0.8-PoC0"/>
    <pdsc name="utility_sequencer" url="file://localhost/C:/Cube20/infra/Firmware/Utilities/sequencer/" vendor="STMicroelectronics" version="0.0.2"/>
    <pdsc name="STM32_SBSFU_MemoryPartitioning" url="file://localhost/C:/R-CUBE-SBSFU/packages/STM32_SBSFU_MemoryPartitioning/" vendor="fred-r" version="0.0.3-PoC0"/>
    <pdsc name="utility_common" url="file://localhost/C:/Cube20/infra/Firmware/Utilities/Common/" vendor="STMicroelectronics" version="0.0.1"/>
    <pdsc name="STM32L5xx_Drivers" url="file://localhost/C:/Cube20/infra/Firmware/drivers/STM32L5xx_HAL_Driver/" vendor="STMicroelectronics" version="0.0.5"/>
    <pdsc name="STM32G4xx_DFP" url="file://localhost/C:/Cube20/infra/Firmware/cmsis/Device/ST/STM32G4xx/" vendor="STMicroelectronics" version="0.0.3"/>
    <pdsc name="lsm6dso" url="file://localhost/C:/Cube20/infra/Firmware/boards/parts/lsm6dso/" vendor="STMicroelectronics" version="0.0.4"/>
    <pdsc name="led" url="file://localhost/C:/Cube20/infra/Firmware/boards/parts/led/" vendor="STMicroelectronics" version="0.0.1"/>
    <pdsc name="cs42l51" url="file://localhost/C:/Cube20/infra/Firmware/boards/parts/cs42l51/" vendor="STMicroelectronics" version="0.0.1"/>
    <pdsc name="board_if_codegen" url="file://localhost/C:/Cube20/infra/Firmware/boards/board_if_codegen/" vendor="STMicroelectronics" version="0.0.1"/>
    <pdsc name="STM32U5xx_DFP" url="file://localhost/C:/Cube20/infra/Firmware/cmsis/Device/ST/STM32U5xx/" vendor="STMicroelectronics" version="0.0.1"/>
  </pindex>

</index>

Describe the bug
cpackget returns with error state when asked to install a pack that is already installed. This leads to CI pipelines to fail.

To Reproduce
Steps to reproduce the behavior:

1. cpackget -R .packs init https://keil.com/pack/index.pidx
2. cpackget -R .packs pack add ARM.CMSIS install the pack:

   I: Using pack root: ".packs"
   I: Downloading ARM.CMSIS.pdsc 100% |█████████████████████████████████| (238/238 kB, 338.772 kB/s)
   I: Adding pack "ARM.CMSIS.5.8.0"
   I: Downloading ARM.CMSIS.5.8.0.pack 100% |██████████████████████████████| (34/34 MB, 30.838 MB/s)
   I: Extracting files to .packs\ARM\CMSIS\5.8.0 100% |█████████████████████| (8133/8133, 207 it/s)
   

3. cpackget -R .packs pack add ARM.CMSIS recognizes pack is already installed
4. See error:

   I: Using pack root: ".packs"
   I: Adding pack "ARM.CMSIS.5.8.0"
   E: pack ARM.CMSIS.5.8.0 is already installed here: .packs\ARM\CMSIS\5.8.0
   

Expected behavior
Reinstalling an already installed pack should not be treated as an error. In the first place it may be a no-op with just info (or at max warning) message. In the second place their might be situations where a user wants to force reinstall a pack. While this can already be achieved by removing and install the pack in two steps, a --force flag for the add command may be convenient. Today, the add -f flag conflicts with the usual abbreviation for --force.

Environment (please complete the following information):

• OS: Windows
• Version: 2020H2

Additional context
Add any other context about the problem here.

Extracted from #58

Reinstalling an already installed pack should not be treated as an error. In the first place it may be a no-op with just info (or at max warning) message. In the second place their might be situations where a user wants to force reinstall a pack. While this can already be achieved by removing and install the pack in two steps, a --force flag for the add command may be convenient. Today, the add -f flag conflicts with the usual abbreviation for --force.

Then I left a comment

I'll address the second part of your issue on another PR. What do you think of --force-reinstall? pip[1] uses that option for exactly the same purpose as you described.
[1] https://pip.pypa.io/en/stable/cli/pip_install/?highlight=reinstall#cmdoption-force-reinstall

Issue extracted from #50 (comment)

since we only have a single "index" -> for public packs only. I think cpackget update-index works well here

Hi

For example, in CMIS_PACK_ROOT/ARM/CMSIS/5.9.0
there is a sha1 file: ARM.CMSIS.sha1

Does cpackget check this file while unzipping pack file?
If some sha1 is failing, is pack rejected ?

More info in https://open-cmsis-pack.github.io/Open-CMSIS-Pack-Spec/main/html/bash_script.html

Thx

Describe the bug
When following the instructions in DEVELOPING.md on macOS, step 6, "Make sure it builds make build/cpackget" results in an ELF executable. Executables on macOS should be Mach-O.

To Reproduce
Steps to reproduce the behavior:

1. Clone a fresh copy of cpackget.git
2. make config
3. make test-all
4. make build/cpackget
5. Try running the built cpackget: ./build/cpackget and see the following error

> ./build/cpackget 
exec: Failed to execute process: './build/cpackget' the file could not be run by the operating system.

6. Verify the file type with file ./build/cpackget.

./build/cpackget: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, Go BuildID=Zh5jYUyruxOUJMyxI5HE/abJ2yU7uhLeJYLPr5KJ1/4O-QgpEeKIapoQvea0Qq/s1syd2_Gpiva6vPioiUc, not stripped

Expected behavior
I would expect following the directions in DEVELOPING.md to result in a successful build of cpackget that I can run on my host system. To accomplish this, make build/cpackget could default to building a binary that runs on the host. Alternatively, we could instruct the user to run a platform-specific command, like make OS=darwin ARCH=amd64 build/cpackget for macOS amd64.

Environment (please complete the following information):

• OS: darwin
• Version e1c32e9 ("Make sure pack version exists in the pdsc file and it is the latest one (#46)")

Additional context
After running make OS=darwin ARCH=amd64 build/cpackget, we verify the type of the build file with ./build/cpackget and get ./build/cpackget: Mach-O 64-bit executable x86_64, which is executable on macOS.

cpackget seems to be unable to download packages when called from behind a corporate VPN (Cisco AnyConnect) + Proxy (Zscaler):

VPN enabled:

PS D:\git\test-project\prj> cpackget pack add Keil.STM32F1xx_DFP.2.4.0
I: Using pack root: "C:\Users\<user>\AppData\Local\Arm\Packs"
I: Adding pack "Keil.STM32F1xx_DFP.2.4.0"
E: Get "http://www.keil.com/pack/Keil.STM32F1xx_DFP.2.4.0.pack": dial tcp 23.11.231.137:80: connectex: No connection could be made because the target machine actively refused it.
E: failed to download file

Now, VPN disabled:

PS D:\git\test-project\prj> cpackget pack add Keil.STM32F1xx_DFP.2.4.0
I: Using pack root: "C:\Users\<user>\AppData\Local\Arm\Packs"
I: Adding pack "Keil.STM32F1xx_DFP.2.4.0"
E: Can't decompress "C:\Users\<user>\AppData\Local\Arm\Packs\.Download\Keil.STM32F1xx_DFP.2.4.0.pack": zip: not a valid zip file
E: fail to decompress file

Keil.STM32F1xx_DFP.2.4.0.pack is now 0 byte in size. Seems like it does not get re-downloaded or size checked.

VPN disabled + deleting Keil.STM32F1xx_DFP.2.4.0.pack:

PS D:\git\test-project\prj> cpackget pack add Keil.STM32F1xx_DFP.2.4.0
I: Using pack root: "C:\Users\<user>\AppData\Local\Arm\Packs"
I: Adding pack "Keil.STM32F1xx_DFP.2.4.0"
I: Downloading Keil.STM32F1xx_DFP.2.4.0.pack 100% |████████████████████████████████████| (48/48 MB, 7.387 MB/s)
I: Extracting files to C:\Users\<user>\AppData\Local\Arm\Packs\Keil\STM32F1xx_DFP\2.4.0 

Works as expected. So I guess there are two issues:

1. System proxy settings are not used
2. Erroneous downloads are not overwritten

cpackget version 0.4.0
Windows 10 21H2

Thanks for this great initiative!

Currently users would add local packs using

$ cpackget pdsc add path/to/ARM.CMSIS.pdsc

and then remove it by running

$ cpackget pdsc rm ARM.CMSIS

Thus not specifying the PDSC path at all.
Since it's possible that the same path can be added multiple times using different paths,

$ cpackget pdsc add one/path/to/ARM.CMSIS.pdsc
$ cpackget pdsc add another/path/to/ARM.CMSIS.pdsc

There is no way to specify which ARM.CMSIS.pdsc is intended for removal.

cpackget should then:

1. Allow users to remove local packs using PDSC file path notation: $ cpackget pdsc rm ARM.CMSIS.pdsc
2. And if there's such case where a single pack was installed using more than one PDSC file path, then cpackget should require the full path of that PDSC file in order to remove it

$ cpackget pdsc rm /absolute/path/to/ARM.CMSIS.pdsc

The user can retrieve the absolute path of the local pack by listing all installed packs (to be implemented by #64 (comment))

Some projects use a version schema that includes mm.yy format. A leading 0 in the month field is not accepted by cpackget due to the strict checking of the semantic versioning format.

See also Open-CMSIS-Pack/Open-CMSIS-Pack-Spec#126

This results in the effect that some packs cannot be installed right now. Example:

I: Using pack root: "C:\Users\reikei01\AppData\Local\Arm\Packs"
E: bad pack name: it should be one of the following formats: Vendor.Pack, Vendor.Pack.x.y.z, Vendor.Pack.x.y.z.pack, or Vendor.Pack.pdsc
E: bad pack name: it should be one of the following formats: Vendor.Pack, Vendor.Pack.x.y.z, Vendor.Pack.x.y.z.pack, or Vendor.Pack.pdsc

NOTE: It appears that errors are printed twice, which seems to be another flaw.

For the time being, I suggest to relax the check for the sematic version by using the definition PackVersionType from PACK.xsd.

<xs:simpleType name="PackVersionType">
    <xs:restriction base="xs:string">
      <!-- major . minor . patch [[-]quality] [+build] -->
      <xs:pattern value="[0-9]+.[0-9]+.[0-9]+((\-[0-9A-Za-z_\-\.]+)|([_A-Za-z][0-9A-Za-z_\-\.]*)|())((\+[\-\._A-Za-z0-9]+)|())" />
    </xs:restriction>
  </xs:simpleType>

See also https://github.com/Open-CMSIS-Pack/Open-CMSIS-Pack-Spec/blob/main/schema/PACK.xsd#L1498

Environment:
cpackget version 0.5.0 (C) 2022 Linaro
Running on Windows 10.

cpackget.exe pdsc add C:/Packs/STMicroelectronics.STM32U5xx_Drivers.0.1.1.pack
I: Using pack root: "C:\CMSIS_PACKS"
I: Adding pdsc
E: XML syntax error on line 1: illegal character code U+0003

pdsc which is not accepted:

<?xml version="1.0" encoding="UTF-8"?> CR LF

pdsc which is accepted:

<?xml version="1.0" encoding="UTF-8"?> LF

> cpackget.exe pack rm STMicroelectronics.Example_HAL_GPIO_Toggle
I: Using pack root: "C:\CMSIS_PACKS"
I: Removing [STMicroelectronics.Example_HAL_GPIO_Toggle]
I: Downloading STMicroelectronics.Example_HAL_GPIO_Toggle.pdsc...

==> is the last step really needed ?

The EULA options string does not contain a space after it. While on Linux that doesn't matter because the answer will be read in by scanf, on Windows the answer will be printed out to the screen along with the EULA option string:

License Agreement: [A]ccept [D]ecline [E]xtractA

The extra "A" after "[E]xtract" is visibly not that good.

Ref: https://github.com/Open-CMSIS-Pack/cpackget/blob/v0.4.1/cmd/ui/eula.go#L43

Hi

Do you think it could be easy and nice to sort each pdsc line in .Local/local_repository.pidx ? :-)

Thx

Background: CMSIS-Build's cbuildgen generates a file with all download urls for packs that are required by a project which are not already installed at the moment.
In order to fully replace the bash script 'cp_install.sh' from CMSIS-Build by 'cpackget' in 'cbuild.sh'

cp_install.sh "${abs_intdir}${project}.cpinstall" >&${out} 2>&${err}

we need to be able to pass a the *.cpinstall to cpackget

cpackget pack add -f "${abs_intdir}${project}.cpinstall"

The file format of the packlist in cpinstall files is straight forward. It contains one url per line with empty lines being skipped over until the EOF is reached.

Enhancement request
Could we get a
cpackget pack list [-cache]
command that provides the list of currently available in the pack root folder and optionally in .download cache folder

> cpackget.exe pack add STMicroelectronics.STM32U5xx_Drivers.2.0.0-alpha.0.5.pack
I: Using pack root: "C:\CMSIS_PACKS"
I: Adding pack "STMicroelectronics.STM32U5xx_Drivers.2.0.0-alpha.0.5.pack"
E: pack version not found in the pdsc file

$ echo $CMSIS_PACK_ROOT
C:\CMSIS_PACKS

$ ls /c/CMSIS_PACKS/.Local/STM*
/c/CMSIS_PACKS/.Local/STMicroelectronics.Example_HAL_GPIO_Toggle.pdsc
/c/CMSIS_PACKS/.Local/STMicroelectronics.board_resources_B-U585I-IOT02A.pdsc

$ ls /c/CMSIS_PACKS/.Web/STM*
/c/CMSIS_PACKS/.Web/STMicroelectronics.STM32U5xx_Drivers.pdsc

frq09468@LMECWL0888 MINGW64 /c/Packs
$ cat /c/CMSIS_PACKS/.Web/STMicroelectronics.STM32U5xx_Drivers.pdsc
<?xml version="1.0" encoding="UTF-8"?>

<package schemaVersion="1.6.0" xmlns:xs="http://www.w3.org/2001/XMLSchema-instance" xs:noNamespaceSchemaLocation="PACK.xsd" Dname="STM32U5*">
  <vendor>STMicroelectronics</vendor>
  <name>STM32U5xx_Drivers</name>
  <description>STMicroelectronics STM32U5 series HAL and LL</description>
  <url>xxxxxxxxxx</url>

  <releases>
    <release version="2.0.0-alpha.0.5" date="2022-04-28">Fix few issues</release>

And:

> cpackget.exe --version
cpackget version 0.4.1

Describe the bug
New pack location init does not work.

To Reproduce

C:\Users\<user>> cpackget init -R .\PACK_TEST\ https://keil.com/pack/index.pidx -v
I: Using pack root: "PACK_TEST"
D: Initializing PidxXML object for "PACK_TEST\.Local\local_repository.pidx"
D: Initializing PidxXML object for "PACK_TEST\.Web\index.pidx"
D: Making sure "PACK_TEST" exists
D: Making sure "PACK_TEST\.Download" exists
D: Making sure "PACK_TEST\.Local" exists
D: Making sure "PACK_TEST\.Web" exists
D: Reading pidx from file "PACK_TEST\.Web\index.pidx"
D: Updating public index with "https://keil.com/pack/index.pidx"
I: Overwriting public index file PACK_TEST\.Web\index.pidx
D: Downloading https://keil.com/pack/index.pidx to PACK_TEST\.Download\index.pidx
D: Downloaded 35731 bytes
D: Initializing PidxXML object for "PACK_TEST\.Download\index.pidx"
D: Reading pidx from file "PACK_TEST\.Download\index.pidx"
E: expected element type <index> but have <html>

The file does exist, but probably not in the correct directory?

Hi

Working with local packs:

cpackget pdsc add <pdsc file>

We got
<pdsc vendor="STMicroelectronics" url=file://localhost/xxx" name="xxx" version="0.0.1"></pdsc>
in the local_repository.pidx

We update the pdsc file, to increase version for example.
We need then to update the version in our local_repository.pidx

cpackget pdsc add <same pdsc file>

We got the same file 2 times:

<pdsc vendor="STMicroelectronics" url=file://localhost/xxx" name="xxx" version="0.0.1"></pdsc>
<pdsc vendor="STMicroelectronics" url=file://localhost/xxx" name="xxx" version="0.0.2"></pdsc>

@VVESTM

Today cpackget requires a download url for downloading and installing a public pack.
Cbuildgen is creating the packlist with download urls for the required packs.
We should implement the translation from packID to download url in cpackget.

cpackget pack add ARM.CMSIS.5.7.0

Note: in case no version is specified the greatest version found is used.

Process:
assumption - file: ARM/CMSIS/5.7.0/ARM.CMSIS.pdsc - does not exist in $CMSIS_PACK_ROOT

if exist $CMSIS_PACK_ROOT/.Download/ARM.CMSIS.5.7.0.pack
  cpackget pack add file://..../.Download/ARM.CMSIS.5.7.0.pack
else
  if not exist $CMSIS_PACK_ROOT/.Web/ARM.CMSIS.pdsc
      if not exist $CMSIS_PACK_ROOT/.Web/index.pidx
          cpackget index https://www.keil.com/pack/index.pidx
      read index.pidx find url for ARM.CMSIS.pdsc
      download $url to $CMSIS_PACK_ROOT/.Web/
  read releases section of ARM.CMSIS.pdsc
  find version 5.7.0
  check if  url attribute is set in <release> or if the default url is constructed 
  cpackget pack add $url

If the package description specifies the license tag the expectation is that any user installing the pack needs to explicitly accept the license before the content of the pack is extracted on the host's drive.

a) the license text needs to be presented in the command window and the user need to hit at least a key to continue installing or cancel the operation
b) a command line option is required which allows to install the pack without user interaction when executed unattended (e.g. CI).
=> do we need a record for which licenses have been silently accepted?

Windows cmd:
cpackget add Arm-Packs::Unity
Pressing key 'd'

E: user does not agree with the pack's license
E: user does not agree with the pack's license

C:\Open-CMSIS-Pack\ctools\bin>

I cannot scroll further up. The first line is the E: which also gets duplicated
Note I am not sure I would consider this an error, as the operation selected by the user was executed successfully.

On Linux, there is a nice window displaying the EULA text. While on Windows that's is not the case.

Describe the bug
cpackget pack add cannot download a pack version older than the latest version listed in the index.pidx.

The error message contains a cpackget command line that is not functional:
cpackget --force index https://keil.com/pack/index.pidx

To Reproduce
Steps to reproduce the behavior:

1. Initialize a new pack repo: cpackget -R .packs init https://keil.com/pack/index.pidx
2. Install some older pack version: cpackget -R .packs pack add ARM.V2M_MPS3_SSE_300_BSP.1.2.0 (note, at this time version 1.3.0 is the latest version of that pack)
3. See error message:

   I: Using pack root: ".packs"
   I: Adding pack "ARM.V2M_MPS3_SSE_300_BSP.1.2.0"
   E: URL for the pack cannot be determined. Please consider updating the public index. Ex: cpackget --force index 
   https://keil.com/pack/index.pidx
   

4. Install the latest version of the pack: cpackget -R .packs pack add ARM.V2M_MPS3_SSE_300_BSP

   I: Using pack root: ".packs"
   I: Downloading ARM.V2M_MPS3_SSE_300_BSP.pdsc 100% || (25/25 kB, 4.686 MB/s)
   I: Adding pack "ARM.V2M_MPS3_SSE_300_BSP.1.3.0"
   I: Downloading ARM.V2M_MPS3_SSE_300_BSP.1.3.0.pack 100% || (4.2/4.2 MB, 24.731 MB/s)
   I: Extracting files to .packs\ARM\V2M_MPS3_SSE_300_BSP\1.3.0 100% || (114/114, 614 it/s)
   

5. Install the older pack version again: cpackget -R .packs pack add ARM.V2M_MPS3_SSE_300_BSP.1.2.0

   I: Using pack root: ".packs"
   I: Adding pack "ARM.V2M_MPS3_SSE_300_BSP.1.2.0"
   I: Downloading ARM.V2M_MPS3_SSE_300_BSP.1.2.0.pack 100% || (5.3/5.3 MB, 24.428 MB/s)
   I: Extracting files to .packs\ARM\V2M_MPS3_SSE_300_BSP\1.2.0 100% || (102/102, 538 it/s)
   

Expected behavior
cpackget is expected to download/install all ever published versions of a pack right into an empty pack folder. Regardless of the version requested, cpackget shall download/update the packs .PDSC file into the .Web folder.

The error message is expected to give a proper command:
cpackget index --force https://keil.com/pack/index.pidx

The --force flag on index seems to be always required. Right after init there is an index.pidx so a user would never be able to update the index without giving the -f flag. It is expected that this is default behaviour so -f flag can be removed.

Environment (please complete the following information):

• OS: Windows
• Version 2020H2

Additional context
Once the pack's .PDSC file is present in the .Web folder the installation of packs works as expected.

Hi

In my CMSIS_PACK_ROOT, I have this pack installed:

|-- STMicroelectronics
|   `-- basic_trace
|       `-- 0.0.1

My index.pidx is correct I think:

$ grep basic_trace .Web/index.pidx
        <pdsc url="https://xxx/STMicroelectronics.basic_trace/" vendor="STMicroelectronics" name="basic_trace" version="0.1.0"/>

I think cpackget should install the new version, but it doesn't:

$ cpackget.exe -V
cpackget version 0.4.1

$ cpackget.exe pack add STMicroelectronics.basic_trace -v
D: Reading pidx from file "C:\xxx\.Web\index.pidx"
D: Registring "STMicroelectronics.basic_trace.0.1.0"
D: Specified packs [STMicroelectronics.basic_trace]
D: Extracting pack info from "STMicroelectronics.basic_trace"
D: Listing files and directories in "C:\xxx\.Web" that match "^.*\.pdsc$"
D: Found "STMicroelectronics.basic_trace.pdsc" in "C:\xxx\.Web"
D: Checking if STMicroelectronics.basic_trace. is installed
I: Adding pack "STMicroelectronics.basic_trace"
I: pack STMicroelectronics.basic_trace is already installed here: C:\xxx\STMicroelectronics\basic_trace

I would expect something like:

D: Found "STMicroelectronics.basic_trace.pdsc" in "C:\xxx\.Web"
D: Checking if STMicroelectronics.basic_trace.0.1.0 is installed
I: Adding pack "STMicroelectronics.basic_trace.0.1.0"

Most development utils like make build on Windows.

$ csolution list packs
ARM::[email protected]
ARM::[email protected]
ARM::[email protected]
ARM::[email protected]
ARM::[email protected]
Keil::[email protected]
Keil::[email protected]
Keil::[email protected]
Keil::[email protected]
Keil::[email protected]
Keil::[email protected]
Keil::[email protected]
Keil::[email protected]
Keil::[email protected]
Keil::[email protected]
Keil::[email protected]
Keil::[email protected]
Keil::[email protected]
Keil::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
STMicroelectronics::[email protected]
fred-r::[email protected]
fred-r::[email protected]
fred-r::[email protected]
fred-r::[email protected]
fred-r::[email protected]

frq09468@LMECWL0888 MINGW64 /c/Packs
$ echo $CMSIS_PACK_ROOT
/c/CMSIS_PACKS

frq09468@LMECWL0888 MINGW64 /c/Packs
$ cpackget pack list
I: Using pack root: "C:/CMSIS_PACKS"
I: Listing installed packs
E: Pack vendor "" does not match ^[0-9a-zA-Z_-]+$
E: A pack in the cache folder has malformed pack name: C:.CMSIS_PACKS.ARM.CMSIS-Driver.2.6.1.pack
E: unknown behavior

Hi, I tested installing a pack using cpackget 0.1.1, but it seems to fail if the pack contains folders.

Steps to reproduce:

1. export CMSIS_PACK_ROOT=c:/test_cmsis
2. ./cpackget.exe -vv pack add https://keilpack.azureedge.net/pack/ARM.CMSIS.5.8.0.pack

...
time="2021-09-03T10:26:25+02:00" level=debug msg="Inflating \"CMSIS/\""
time="2021-09-03T10:26:25+02:00" level=debug msg="Ensuring \"c:\\test_cmsis\\ARM\\CMSIS\\5.8.0\\CMSIS\\\" directory exists"
time="2021-09-03T10:26:25+02:00" level=error msg="open c:\\test_cmsis\\ARM\\CMSIS\\5.8.0\\CMSIS: is a directory"
Error: failed to create a local file

Tested using Git-bash on windows.

There is an incompatibility issue with cbuild when using local pdsc files added through the "cpackget pdsc add some.pdsc"

1. The $CMSIS_PACK_ROOT/.Local/local_repository.pidx file does not contain:

<?xml version="1.0"?>

on the first line, making cbuild failing to parse the file.

2. The urls in are badly formatted as "file://C:/some/path", when it needs to be "file://localhost/C:/some/path" for cbuild to find it.
   https://github.com/Open-CMSIS-Pack/devtools/blob/9859231934deabea689219335fd6ba518e156e27/tools/buildmgr/cbuild/src/CbuildProject.cpp#L276

https://en.wikipedia.org/wiki/File_URI_scheme

Extracted from #35

cpackget list arm show all packs from Arm
cpackget list st show all packs that include the letters st in the file name

Describe the bug
When running cpackget list the output contains the info message 'blaaaaa'

To Reproduce
Steps to reproduce the behavior:

1. run cpackget list
2. See info:

C:\Open-CMSIS-Pack\ctools\bin>cpackget list
I: Using pack root: "c:\CMSIS-PACKS"
I: Listing installed packs
I: blaaaaa
I: AmbiqMicro::[email protected]
...

Expected behavior

C:\Open-CMSIS-Pack\ctools\bin>cpackget list
I: Using pack root: "c:\CMSIS-PACKS"
I: Listing installed packs
I: AmbiqMicro::[email protected] 'blaaaaa' in the output of listed packs
...

Environment (please complete the following information):

• OS: windows 10
• Version 0.5.0

Additional context
utils.go line 291
func CleanPath
log.Info("blaaaaa")

trying this:

> cpackget.exe pack add C:/Packs/STMicroelectronics.STM32U5xx_DFP.0.1.1.pack
I: Using pack root: "C:\CMSIS_PACKS"
E: The pack's pdsc (C:\CMSIS_PACKS\.Local\STMicroelectronics.STM32U5xx_DFP.pdsc) has no release tag matching version "0.1.1"
E: pack version not found in the pdsc file

I have this in my local pack's pdsc:

<releases>
	<release version="0.1.0-alpha1" date="2022-03-09">Add U5_GFX and U5_4M devices</release>
	<release version="0.0.1" date="2021-03-01">Initial release of STM32U5 Device Family Pack.</release>
</releases>

The cpackget tool is already quite good and this is a proposal to improve the usability.

I have not fully understood the PDSC command. How does this differ from the PACK command?

I suggest to simplify the command entry by:

• accept a single character as alternative
• use separate commands for pack

Usage could look like:

Usage:
  cpackget [command] [flags]

command:
  add         Download or install a pack to local pack root
  init          Initialize or update the local pack root
  help        Help about any command
  list           List all packs
  remove   Delete a pack from local pack root
  purge      Remove a pack from local pack root and download cache

flags:
  -h, --help               help for cpackget
  -R, --pack-root string   Specifies pack root folder. Defaults to CMSIS_PACK_ROOT environment variable (default "C:\\Keil_v5\\ARM\\PACK")
  -q, --quiet              Run cpackget silently, printing only error messages
  -v, --verbose            Sets verboseness level: None (Errors + Info + Warnings), -v (all + Debugging). Specify "-q" for no messages
  -V, --version            Prints the version number of cpackget and exit

Use "cpackget [command] --help" for more information about a command.

For example the cpackget list command could be written as cpackget l. It could show all available packs from the index.pidx file and indicate that packs are installed with - installed. It could also have the option to filter, for example with:

• cpackget list arm show all packs from Arm
• cpackget list *st* show all packs that include the letters st in the file name

The cpackget add command could automatically download the pack, if it is available in the index.pidx file from the host service, this would reduce the command to:

• cpackget add ABOV.A31G21x_Series.1.5.1.pack

Describe the bug
Thanks for this first cpackget version.

My $CMSIS_PACK_ROOT folder contained an old test pack with files like:
vendor.pack_name.0.0.2.pack
vendor.pack_name.0.0.2.pdsc
vendor.pack_name.0.0.2.lic.txt

After command
./cpackget.exe pack rm --purge vendor.pack_name
the .pack and .pdsc is well removed, but .lic.txt is still there.

To Reproduce
Steps to reproduce the behavior:

1. Install a pack with specific licence file .lic.txt
2. Run the cpackget with the following args...
   ./cpackget.exe pack rm --purge vendor.pack_name
3. Check if .lic.txt file is well removed or not

Expected behavior
I would expect .lic.txt file to be removed

Environment (please complete the following information):

• OS: [e.g. windows/linux/darwin]
  windows with git bash
• Version [e.g. v0.0.3]
  today's main (cpackget -V doesn't return a version as of now)

Extracted from

• #64 (comment)

chaws and brondani could we please align on the output of the tools (cpackget and csolution) when we list packs?
a) probably we should use the ::@ format
b) specify the location of pack versions that come from
$CMSIS_PACK_ROOT/.Local/local_repository.pidx
*.csolution.yml with solution relative path (csolution only!)

• and #64 (comment)

For listing packs, I would propose to use the same format as in the *.yml files: https://github.com/Open-CMSIS-Pack/devtools/blob/main/tools/projmgr/docs/Manual/YML-Format.md#pack-name-conventions
This is inline with jkrech suggestion to use :: @ in the output.

In my company we are working behind a proxy.

I am under the impression that when I use pack management tools (cpackget or uvision) then some internet accesses are made and alter my pidx file because of the proxy:
C:\CMSIS_PACKS.Web\index.pidx:

...

Is it possbile to:
- either handle the proxy
- or have a mode with only local files ?

Describe the bug
Cpackget should raise an error when specifying a minimum version that does not exist

To Reproduce
Steps to reproduce the behavior:

$ cpackget pack add "ARM::CMSIS>=10.0.0"
I: Using pack root: "../packroot"
I: Adding pack "ARM::CMSIS>=10.0.0"
I: Extracting files to ../packroot/ARM/CMSIS/5.8.0 100% |████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| (8133/8133, 7742 it/s)

Expected behavior
I think in this case, the expected behavior should be an error message saying that the desired version is not available in any PDSC file

DRAFT

Pack Signing Motivation

This is a proposal to make cpackget installation more secure through pack signing by tackling the following top use cases:

1. Integrity: make sure a pack has not been altered during its transport
2. Authenticity: make sure a pack supposed to be issued by a Vendor is really coming from Vendor
3. Access Control: accept some packs only if they are coming from some vendors

Design

The fundamental idea is to use keys signed by PKI/x509 certificates to sign packs and be later on validated by cpackget.

Each vendor would be responsible for generating their Root CA, then generate sub-certificates depending on their needs. Example:

1. ARM Root CA
   1.1. MCU Group Cert
   1.1.1. Joachim Krech's Cert
2. ST Root CA
   2.1. Software Center Cert
   2.1.1. Le Mans Cert
   2.1.1.1. Frederic Ruelle Cert
3. NXP Root CA
   3.1. Bob Cert

Aspects of the approach:

1. All Root CA will be shipped in cpackget's secure store of certs (customizable).
2. If Frederic Ruelle signed a pack with his key, cpackget can:
   2.1. Check integrity by checking the signature file and the original pack file
   2.2. Validate its authenticity because it has been signed by MCU Group Cert which has been signed by ARM Root CA, present in the certs store.
   2.3. Optionally check access control by matching the key's cert against the specific Root CA.
3. Because keys and certs can be revoked at any time, the public key should not have any reference in the pdsc file.
4. Cpackget can be told on the behavior when checking a pack signature via cmdline args, such as --ignore-validity-date or --ignor-ownership

Q&A

The following questions have been asked during discussion of this proposal:

Q1: How to ensure that the pack file has not been modified?
The signature file is just an encrypted hash sum of the pack file, so during signature checking, the hash of the pack will be re-generated and compared against the one embedded in the signature file.

Q2: How to ensure that the pack was created by the vendor?
Because of the nature of X.509 certs, it's possible to track a signing key up to its original ROOT CA. All Root CAs should be in a secure store trusted by cpackget.

Q3: If a pack was signed by a key that is no longer valid, is there a solution without re-signing all packs signed with that key?
No, re-signing is required because the key is no longer trusted by cpackget.

It is unclear if the extension *.pack is supported when specifying packs.

I found the following inconsistency:

PS C:\Test\Demo_EW> cpackget rm AWS.FreeRTOS_LTS.2020.12.1-Beta.pack
I: Using pack root: "C:\Users\reikei01\AppData\Local\Arm\Packs"
I: Removing [AWS.FreeRTOS_LTS.2020.12.1-Beta.pack]
PS C:\Test\Demo_EW> cpackget add AWS.FreeRTOS_LTS.2020.12.1-Beta.pack
I: Using pack root: "C:\Users\reikei01\AppData\Local\Arm\Packs"
I: Adding pack "AWS.FreeRTOS_LTS.2020.12.1-Beta.pack"
E: File "AWS.FreeRTOS_LTS.2020.12.1-Beta.pack" does't exist

While the command rm seems to accept the extension *.pack, the command add seems not to handle it.

NOTE: without extension *.pack the expected result is generated.

Environment:
cpackget version 0.5.0 (C) 2022 Linaro
Running on Windows 10.

Pack installation on Linux is much faster if compared to Windows. Part of the installation process consists of extracting the files in the pack, and this is done via Golang's stdlib. Perhaps that is not the best way to do on Windows?

For example, when writing files on Windows it spawns a new process for that, so if the cpackget tries to change the same file's content, it fails on Windows but not on Linux.

Issue reported by @jkrech :

C:\tmp\demo>c:\arm\cmsis-toolbox\bin\cpackget.exe index https://www.keil.com/pack/index.pidx
I: Using pack root: "C:\Users\jkrech\AppData\Local\Arm\Packs"
E: directory not found

In this case it is not clear to the user what directory is not found. The directory displayed actually exists but the .Web folder does not.

According to the help:

$ cpackget init --help
Initializes a pack root folder specified by -R/--pack-root command line
or via the CMSIS_PACK_ROOT environment variable with the following contents:
  - .Download/
  - .Local/
  - .Web/
  - .Web/index.pidx (downloaded from <index-url>)

But:

$ cpackget init -R ./packroot/
I: Using pack root: "./packroot/"
W: "packroot\.Web\index.pidx" not found. Creating a new one.

$ tree -a
.
|-- .Download
|-- .Local
`-- .Web
    `-- index.pidx

3 directories, 1 file

$ cat .Web/index.pidx
<?xml version="1.0" encoding="UTF-8"?>
<index schemaVersion="1.1.0">
 <vendor>packroot\.Web\index</vendor>
 <url></url>
 <pindex></pindex>
</index>

[Q1] .Web/index.pidx ==> where is it downloaded from ? What is <index-url> ?

Then we can install a pack:

$ cpackget pack add https://xxxxx/STMicroelectronics.STM32U5xx_DFP.0.1.0-alpha1.pack -R .
I: Using pack root: "."
I: Adding pack "STMicroelectronics.STM32U5xx_DFP.0.1.0-alpha1"
I: Downloading STMicroelectronics.STM32U5xx_DFP.0.1.0-alpha1.pack 100% || (2.2/2.2 MB, 1.414 MB/s)
I: Extracting files to STMicroelectronics\STM32U5xx_DFP\0.1.0-alpha1 100% || (49/49, 185 it/s)

And we end up with :

$ tree -a
.
|-- .Download
|   |-- STMicroelectronics.STM32U5xx_DFP.0.1.0-alpha1.pack
|   `-- STMicroelectronics.STM32U5xx_DFP.0.1.0-alpha1.pdsc
|-- .Local
|   `-- STMicroelectronics.STM32U5xx_DFP.pdsc
|-- .Web
|   `-- index.pidx
|-- STMicroelectronics
|   `-- STM32U5xx_DFP
|       `-- 0.1.0-alpha1
|           |-- Flash
|           |-- Include
|           |-- STMicroelectronics.STM32U5xx_DFP.pdsc
|           `-- Source
`-- pack.idx

[Q2] Why this architecture with files duplication ?
The .pack is kept in .Download, why ?
The .pdsc is present in multiple places, why ? Why in .local especially ?

Also:

$ cat pack.idx

[Q3] What is pack.idx ? Why is it empty ?

[Q4] As you know, we also want the possibility to have standalone projects with a local copy of packs. Will we have to apply this structure ? We want to follow our own files organization.

Describe the bug
Progressbar doesn't work nicely on non-interactive terminals

To Reproduce
Run cpackget on a non-interactive terminal:
https://github.com/ARM-software/AVH-AWS_MQTT_Demo/runs/5509057511?check_suite_focus=true#step:4:1345

Expected behavior
It would be nice if cpacket could detect the missing terminal feature and just display a static message

Describe the bug
On windows the help message for -R option is somewhat confusing

Instead of:

  -R, --pack-root string   Specifies pack root folder. Defaults to CMSIS_PACK_ROOT environment variable (default "C:\\Users\\reikei01\\AppData\\Local\\Arm\\Packs")

It should be:

  -R, --pack-root string   Specifies pack root folder. Defaults to CMSIS_PACK_ROOT environment variable (default "C:\Users\reikei01\AppData\Local\Arm\Packs")

To Reproduce
Steps to reproduce the behavior:

1. Run the cpackget on Windows 10 with the following command line

cpackget add -h

Note that this issue might exist in other places too.

With the command cpackget index -h (on Windows) there is another misleading output.

Instead of:

Updates the public index in CMSIS_PACK_ROOT/.Web/index.pidx using the file specified by the given url.

it could be

Updates the public index in %CMSIS_PACK_ROOT%/.Web/index.pidx using the file specified by the given url.

I believe the %CMSIS_PACK_ROOT% notation also works on Linux

Describe the bug
Running cpackget on Windows to update the index.pidx file fails with:

$ cpackget index -f https://www.keil.com/pack/index.pidx
I: Using pack root: "C:\Users\xxx\AppData\Local\Arm\Packs"
I: Updating index [https://www.keil.com/pack/index.pidx]
I: Overwriting public index file C:\Users\xxx\AppData\Local\Arm\Packs\.Web\index.pidx
E: Can't move file "C:\Users\xxx\AppData\Local\Arm\Packs\.Download\index.pidx" to "C:\Users\xxx\AppData\Local\Arm\Packs\.Web\index.pidx": rename C:\Users\xxx\AppData\Local\Arm\Packs\.Download\index.pidx C:\Users\xxx\AppData\Local\Arm\Packs\.Web\index.p
idx: Access is denied.
E: rename C:\Users\xxx\AppData\Local\Arm\Packs\.Download\index.pidx C:\Users\xxx\AppData\Local\Arm\Packs\.Web\index.pidx: Access is denied.

To Reproduce
Steps to reproduce the behavior:

1. Initialize/update pack folder using MDK's PackInstaller
2. Run cpackget index -f https://www.keil.com/pack/index.pidx
3. See error from above

Expected behavior

• It is expected that cpackget overwrites the existing index.pidx.
• It is expected that cpackget sets all files in the pack folder to read-only.

Environment (please complete the following information):

• OS: Windows
• Version 20H2 (19042.1586)
• MDK 5.36

When using the cpackget pack list command it appears to stop on the first pack that uses inconsistent naming conventions.

cpackget pack list
I: Using pack root: "C:\Keil_v5\ARM\PACK"
I: Listing installed packs
I: AmbiqMicro.Apollo_DFP.1.2.0
I: Arm-Packs.PKCS11.1.0.0
I: ARM.AMP.1.1.0
I: ARM.CMSIS-Driver.2.6.0
I: ARM.CMSIS-Driver.2.6.1
I: ARM.CMSIS-Driver_Validation.2.0.0
I: ARM.CMSIS-FreeRTOS.10.0.1
I: ARM.CMSIS-FreeRTOS.10.3.0
I: ARM.CMSIS-FreeRTOS.10.3.1
I: ARM.CMSIS-FreeRTOS.10.4.3
I: ARM.CMSIS-FreeRTOS.10.4.6
I: ARM.CMSIS.5.7.0
I: ARM.CMSIS.5.8.0
I: ARM.CMSIS_ARMv81M.1.0.0
E: Pack version "0.0.1.20210416" does not match ^(0|[1-9][0-9]*)\.(0|[1-9][0-9]*)\.(0|[1-9][0-9]*)(-(0|[1-9][0-9]*|[0-9]*[a-zA-Z-][0-9a-zA-Z-]*)(\.(0|[1-9][0-9]*|[0-9]*[a-zA-Z-][0-9a-zA-Z-]*))*)?(\+[0-9a-zA-Z-]+(\.[0-9a-zA-Z-]+)*)?$
E: A pack in the cache folder has malformed pack name: ARM.ethos-u-core-driver.0.0.1.20210416.pack
E: unknown behavior

I would also suggest to use a unified error messaging format as proposed here: Open-CMSIS-Pack/devtools#1315

The output could read:

CMSIS_PACK_ROOT="C:\Keil_v5\ARM\PACK"
AmbiqMicro.Apollo_DFP.1.2.0
Arm-Packs.PKCS11.1.0.0
ARM.AMP.1.1.0
ARM.CMSIS-Driver.2.6.0
ARM.CMSIS-Driver.2.6.1
ARM.CMSIS-Driver_Validation.2.0.0
ARM.CMSIS-FreeRTOS.10.0.1
ARM.CMSIS-FreeRTOS.10.3.0
ARM.CMSIS-FreeRTOS.10.3.1
ARM.CMSIS-FreeRTOS.10.4.3
ARM.CMSIS-FreeRTOS.10.4.6
ARM.CMSIS.5.7.0
ARM.CMSIS.5.8.0
ARM.CMSIS_ARMv81M.1.0.0
ARM.ethos-u-core-driver.0.0.1.20210416.pack - error: pack version incorrect format
ARM.nextpack.1.0.0
   :
info: 1 error(s) detected

Issue extracted from #50 (comment)

a) let's make index-url mandatory - where index-url may point to a local index.pidx file being e.g. generated using vidx2pidx or a a schema compliant file without entries

I have a question regarding the documentation section https://github.com/Open-CMSIS-Pack/cpackget/blob/main/README.md#removing-packs

What is the difference between

• removing packs (the first 2 examples)
• removing packs that were installed via PDSC file (the last 2 examples)

Is this just an artifact of the previous command versions or is there more to it?

The section https://github.com/Open-CMSIS-Pack/cpackget#working-behind-a-proxy explains the configuration of a Proxy.

When would I need to configure that? Are there any error messages printed?

And as a user, how would I find the name of the PROXY that I need to specify?

cmsis-toolbox 0.9.1

Issue with pack versioning ?

$ cpackget pack rm STMicroelectronics::[email protected]
E: bad pack name: pack version should be versioned like 0.0.0, and optionally have a suffix containing letters