Announcing our npackd fork

[GoogleCodeExporter]

Hello there, 

Firtstly, I agree that this is not an issue at all but it seems that this is 
the only place (other than twitter) where I can publicly post to the npackd 
community.

I am writing you to announce that we (at my company, HydrOcean) are currently 
working on a customized (not a lot) version of npackd (wpmcpp). 

This version aims different goals: 

*** Give our internal users an already configured and ready to use installation 
for our custom repositories ***

Our users no longer have to set custom repositories and directories, everything 
is embedded in our own versions of the installers. Also, we now can apply 
specific rules like the possibility to reinstall msi packages when externally 
installed but detected by npackd. Allowing things like defining a same package 
installation directory as the one managed by npackd and reusing it in a 
<variable> dependency property. 

*** Improve npackd (wpmcpp) with internally developed functionalities which we 
expected to have on the official version ***

As we cannot afford waiting for the required functionalities to be developed, 
we have to develop it by ourselves and eventually push them to the official 
repositories if useful for the masses. We are already proceeding this way on 
(GNU/) Linux with the NixOS distribution <http://nixos.org> and it is working 
like a charm, close to the community. If you are interested in *nix, I 
recommend you to look at it, the Nix package manager (on which it is based on) 
aims to be the "state of the art" one. 

*** Improve our internal stability by fully manage our package management 
system ***

Thanks to this "parallel" version, we should be able to upgrade out entire 
computer base packages while being sure of the actions being applied by the 
update processes and eventually customizing it. 

*** Respect the GPL ***

Because npackd is licensed over the GPL, we must publish the source code when 
redistributed. Even if we currently do not plan to do so, we may have to 
redistribute it to our clients or partners (USB/DVD installers, development 
environment builders, ...) aside of our commercially developed software. 

Be aware that our goal is only to make our npackd custom version working 
exactly as we expect, we do not intend at all to take some leadership over the 
official npackd project or to affect how the software should work for the 
others. We have totally different commercial activities and we do not intend to 
invest on npackd more than making it work as we expect for our own 
requirements. 

Because all of our internal code is based on git and we do not have the time to 
handle one more SCM system, we have published our fork of npackdcpp on github 
at the url <https://github.com/HydrOcean/npackdcpp>. We would enjoy some 
discussions about the commits and eventually merge them to the official source 
code if you want to ;-)

Finally, as we have already started to work on the source code, here are some 
of the changes already pushed on our branch that the community may appreciate 
(much more detailed descriptions are available in the commit descriptions on 
<https://github.com/HydrOcean/npackdcpp/commits/ho-master>):
* Ask the user to create the npackd installation path if it does not exists
* Set the default installation directory to `QDir::rootPath() + "npackd"
* Support invalid certificate authorities by prompting the user
* Support local repositories and files
* Possibility to create directory trees for the <important-file> shortcuts
* Source code compatible with Visual C++ 2010 (no npackcl yet; should also be 
OK for other VC++ versions compatible with Qt 4)
* Installers for VC10 32 and 64 bit

Original issue reported on code.google.com by bbenoist...@gmail.com on 19 Jun 2013 at 11:09

[GoogleCodeExporter]

Oops I did not see the type of issue before submitting my post :-/ For me it's 
more an enhancement than a defect of course ;-)

Original comment by bbenoist...@gmail.com on 19 Jun 2013 at 11:30

[GoogleCodeExporter]

thank you for publishing your changes. This is great and the biggest C++ 
contribution so far. It will take me some time to look through all the changes 
and decide how they can be used. I'll answer here. BTW, all issues start as 
defects and users cannot change this.

Original comment by tim.lebe...@gmail.com on 20 Jun 2013 at 7:48

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Glad you appreciated. Source code hosting services such as googlecode and 
github sucks on things which are not directly related with the code of a 
project...

As we really miss such a functionality (it is annoying to inform any employee 
about manual updates), I am currently working on a solution allowing Npackd to 
automatically update itself. Even if I am near a working concept, any precedent 
reflexion on the subject may help ;-)

Original comment by bbenoist...@gmail.com on 23 Jun 2013 at 5:17

[GoogleCodeExporter]

I would probably specifically check for the presence of the package removal 
operation for com.googlecode.windows-package-manager.Npackd. I am not sure what 
would be the best way to remove it later, but there are at least these 3 
options: create a copy of all Npackd files in the system temporary directory, 
start "npackdcl.exe remove" or implement command line package removal for 
Npackd.

Original comment by tim.lebe...@gmail.com on 24 Jun 2013 at 8:58

[GoogleCodeExporter]

could you please check if __x86_64__ is available in MSVC? I use it to detect 
the 64 bit target.

Original comment by tim.lebe...@gmail.com on 25 Jun 2013 at 9:03

[GoogleCodeExporter]

file:// support was merged. Thank you.

Original comment by tim.lebe...@gmail.com on 2 Nov 2014 at 10:36