Re: [Slackbuilds-users] KeePass.SlackBuild

[Thomas Szteliga]

On 28.08.2016 00:53, Doogster wrote:

I would have suggested adding a KEEPASS_VERSION option to the plugin's
SlackBuild.



OK, but I don't see how this would solve the problem?

Short example:

Keepass v.2.30
Plugin: KeePassHttp v. 1.8.4.1

How would you name the compiled plugin package and not make tools
like slackpkg/slpkg to go crazy when upgrading?

As I mentioned in my previous post, other distributions
have "normal" locations, like:


Centos: /usr/lib/keepass
Arch: /usr/share/keepass
Ubuntu: /usr/lib/keepass2


--
Thomas Szteliga




smime.p7s
Description: S/MIME Cryptographic Signature
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] KeePass.SlackBuild

[Thomas Szteliga]

On 27.08.2016 09:39, B Watson wrote:

On 8/26/16, Thomas Szteliga  wrote:

they should be placed in:
/usr/lib/KeePass-${VERSION}/
And we can't really determine the version of Keepass
a user has installed in an extension SlackBuild, can we?

Never used KeePass, but to play the devil's advocate...
Why not? There's surely a way for a shell script to determine the version
number. Maybe by running 'KeePass --version' or similar, or maybe even
by just looking for the existence of /usr/lib/KeePass-* and using cut
or whatever to get the version number. Not saying that's a great idea,
but it's at least possible...



Sure, in a SlackBuild that's possible, but in a packaged binary
not really. I'm not saying that's not possible, but how should
we then name the plugin packages?

keepasshttp-for-keepass-2.30 ?

and what about automated upgrades? This is why I think that's
not the best way.



Whether or not that's a good idea partly depends on whether compiled
plugins are compatible from one KeePass version to another. If they are,
then your idea sounds like the best answer. If they aren't, then the
user's going to have to upgrade every plugin after upgrading KeePass
anyway, and if it's like e.g. perl or older versions of irssi, trying
to load an old/incompatible compiled module might cause the whole thing
to segfault...
Not being a KeePass user I can't answer that (looks like KeePass
is written in C# and built with mono, so I don't know enough to even
guess), but it's something you might want to investigate before making
any final decisions.



Plugins for Keepass2 should be compatible with all 2.x versions.
Plugins don't need to be compiled, they come mostly in the form
of a plgx file:

"PLGX is an optional plugin file format for KeePass ≥ 2.09. Instead of
compiling your plugin to a DLL assembly, the plugin source code files
can be packed into a PLGX file and KeePass will compile the plugin
itself when loading it. The advantage of this approach is that plugins
don't need to be recompiled by the plugin developers for each KeePass
release anymore (as KeePass compiles the plugin itself, the generated
plugin assembly references the current, correct KeePass assembly).
Instead of shipping a plugin DLL assembly, you ship the PLGX."



Plugin example: https://github.com/pfn/keepasshttp


In the readme for keepasshttp you can find:

"Non-Windows / Manual Windows installation

 1. Download KeePassHttp
 2. Copy it into the KeePass directory
 + default directory in Ubuntu14.04: /usr/lib/keepass2/
 + default directory in Arch: /usr/share/keepass"


--
Thomas Szteliga





smime.p7s
Description: S/MIME Cryptographic Signature
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] KeePass.SlackBuild

[Andrzej Telszewski]

On 27/08/16 04:20, Thomas Szteliga wrote:


My suggestion is to install KeePass in

/usr/lib/KeePass/


I would vote for this solution, which seems to be the rather standard 
way here on SBo. So why brake it?


The user itself has to know that he might need to rebuild the plugins 
after upgrading the main application.


This sometimes happens to me, when I need to rebuild a few dependent 
packages, after I upgraded python3. For example :-)


--
Best regards,
Andrzej Telszewski
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] KeePass.SlackBuild

[Doogster]

I would have suggested adding a KEEPASS_VERSION option to the plugin's
SlackBuild.

On Sat, Aug 27, 2016 at 12:39 AM, B Watson  wrote:
> On 8/26/16, Thomas Szteliga  wrote:
>
>> they should be placed in:
>>
>>   /usr/lib/KeePass-${VERSION}/
>>
>>
>> And we can't really determine the version of Keepass
>> a user has installed in an extension SlackBuild, can we?
>
> Never used KeePass, but to play the devil's advocate...
>
> Why not? There's surely a way for a shell script to determine the version
> number. Maybe by running 'KeePass --version' or similar, or maybe even
> by just looking for the existence of /usr/lib/KeePass-* and using cut
> or whatever to get the version number. Not saying that's a great idea,
> but it's at least possible...
>
>> My suggestion is to install KeePass in
>>
>>   /usr/lib/KeePass/
>>
>> or just symlink /usr/lib/KeePass to /usr/lib/KeePass-${VERSION}
>> in doinst.sh.
>>
>> This would make the creation of extension/plugin SlackBuilds
>> easier, or better - possible.
>
> Whether or not that's a good idea partly depends on whether compiled
> plugins are compatible from one KeePass version to another. If they are,
> then your idea sounds like the best answer. If they aren't, then the
> user's going to have to upgrade every plugin after upgrading KeePass
> anyway, and if it's like e.g. perl or older versions of irssi, trying
> to load an old/incompatible compiled module might cause the whole thing
> to segfault...
>
> Not being a KeePass user I can't answer that (looks like KeePass
> is written in C# and built with mono, so I don't know enough to even
> guess), but it's something you might want to investigate before making
> any final decisions.
>
> I haven't got a horse in this race though.
> ___
> SlackBuilds-users mailing list
> SlackBuilds-users@slackbuilds.org
> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - https://slackbuilds.org/faq/
>
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] KeePass.SlackBuild

[B Watson]

On 8/26/16, Thomas Szteliga  wrote:

> they should be placed in:
>
>   /usr/lib/KeePass-${VERSION}/
>
>
> And we can't really determine the version of Keepass
> a user has installed in an extension SlackBuild, can we?

Never used KeePass, but to play the devil's advocate...

Why not? There's surely a way for a shell script to determine the version
number. Maybe by running 'KeePass --version' or similar, or maybe even
by just looking for the existence of /usr/lib/KeePass-* and using cut
or whatever to get the version number. Not saying that's a great idea,
but it's at least possible...

> My suggestion is to install KeePass in
>
>   /usr/lib/KeePass/
>
> or just symlink /usr/lib/KeePass to /usr/lib/KeePass-${VERSION}
> in doinst.sh.
>
> This would make the creation of extension/plugin SlackBuilds
> easier, or better - possible.

Whether or not that's a good idea partly depends on whether compiled
plugins are compatible from one KeePass version to another. If they are,
then your idea sounds like the best answer. If they aren't, then the
user's going to have to upgrade every plugin after upgrading KeePass
anyway, and if it's like e.g. perl or older versions of irssi, trying
to load an old/incompatible compiled module might cause the whole thing
to segfault...

Not being a KeePass user I can't answer that (looks like KeePass
is written in C# and built with mono, so I don't know enough to even
guess), but it's something you might want to investigate before making
any final decisions.

I haven't got a horse in this race though.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

[Slackbuilds-users] KeePass.SlackBuild

[Thomas Szteliga]

Hello.

The current KeePass.SlackBuild 


makes it impossible to create SlackBuilds for KeePass plugins
and extensions , because
they should be placed in:

/usr/lib/KeePass-${VERSION}/


And we can't really determine the version of Keepass
a user has installed in an extension SlackBuild, can we?
I think going this way would not really make sense.


My suggestion is to install KeePass in

/usr/lib/KeePass/

or just symlink /usr/lib/KeePass to /usr/lib/KeePass-${VERSION}
in doinst.sh.


This would make the creation of extension/plugin SlackBuilds
easier, or better - possible.


--
Thomas Szteliga




smime.p7s
Description: S/MIME Cryptographic Signature
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/