Created attachment 186438 [details] svn diff The current version in the ports tree (2.3.2) was released 14 Dec 2013. 2.4.1 was released 26 Nov 2015, but hasn't made it into the ports tree yet. portlint -C: looks fine. poudriere testport ok: 10.3-RELEASE amd64 10.3-RELEASE i386 10.3-RELEASE arm.armv6 11.0-RELEASE amd64 11.0-RELEASE i386 11.0-RELEASE arm.armv6 11.1-RELEASE amd64 11.1-RELEASE i386
This is a perfectly valid point, however, v2.4 has introduced a new database file format that is incompatible with the older one (<2.4). As I'm not that well versed in the FreeBSD ports infrastructure, and I really don't know how to handle this transition, the port had unfortunately stuck at this version.
I see, perhaps the best way forward is to create a new port (kc24) with bundled instructions on how to convert from the old database format?
I'm up for it. I mean, if this is the way to go, and a customary way to handle this case in FreeBSD, then I'll submit a new port for kc24. Should we perhaps ask a "ports janitor"?
(In reply to leva from comment #3) That's a fine way to handle it. In this case, you probably want to go ahead and pick an expiration time for when to get rid of the old version. So please submit a patch which creates the new version and sets the deprecation/expiration for the old one.
ping
Created attachment 190971 [details] svn diff that adds kc24 and deprecates the old kc in a year Then I propose this patch. It: - adds security/kc24 as a new port with options PCRE SCRYPT LIBEDIT READLINE and a pkg-message with a warning about the incompatible database format - deprecates security/kc on 2019-03-01 (change the date if it should be different) - makes sure the two ports CONFLICT with each other I've tested that it builds and runs on: FreeBSD 10.3 amd64/i386 FreeBSD 10.4 amd64/i386 FreeBSD 11.1 amd64/i386 portlint -C: looks fine (on both)
Thank you for picking this up! One note from me would be to not enable READLINE explicitly, because runtime editline and readline support is mutually exclusive. By default (if you don't define READLINE at compile time, that is) it'll use libedit, and this was the case with the previous version. I think this should stay the same. Daniel
(In reply to leva from comment #7) That is the idea. It keeps LIBEDIT as a default enabled option: OPTIONS_DEFAULT=PCRE SCRYPT LIBEDIT and gives the user radio buttons to choose between LIBEDIT and READLINE: OPTIONS_RADIO_CLI=LIBEDIT READLINE When compiled with READLINE, it gets linked to libreadline.so: root@fbsd11-1-portswrk:~ # ldd /usr/local/bin/kc /usr/local/bin/kc: libcrypto.so.8 => /lib/libcrypto.so.8 (0x800a00000) libxml2.so.2 => /usr/local/lib/libxml2.so.2 (0x800e69000) libreadline.so.7 => /usr/local/lib/libreadline.so.7 (0x8011fe000) <--- libncurses.so.8 => /lib/libncurses.so.8 (0x80144f000) libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x8016a4000) libscrypt.so.0 => /usr/local/lib/libscrypt.so.0 (0x80191f000) libc.so.7 => /lib/libc.so.7 (0x801b26000) libz.so.6 => /lib/libz.so.6 (0x801ede000) liblzma.so.5 => /usr/lib/liblzma.so.5 (0x8020f7000) libm.so.5 => /lib/libm.so.5 (0x802320000) libncursesw.so.8 => /lib/libncursesw.so.8 (0x80254b000) libthr.so.3 => /lib/libthr.so.3 (0x8027a9000) When compiled with LIBEDIT, it gets linked to libedit.so: root@fbsd11-1-portswrk:~ # ldd /usr/local/bin/kc /usr/local/bin/kc: libcrypto.so.8 => /lib/libcrypto.so.8 (0x800a00000) libxml2.so.2 => /usr/local/lib/libxml2.so.2 (0x800e69000) libedit.so.0 => /usr/local/lib/libedit.so.0 (0x8011fe000) <--- libncursesw.so.8 => /lib/libncursesw.so.8 (0x801432000) libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x801690000) libscrypt.so.0 => /usr/local/lib/libscrypt.so.0 (0x80190b000) libc.so.7 => /lib/libc.so.7 (0x801b12000) libz.so.6 => /lib/libz.so.6 (0x801eca000) liblzma.so.5 => /usr/lib/liblzma.so.5 (0x8020e3000) libm.so.5 => /lib/libm.so.5 (0x80230c000) libncurses.so.8 => /lib/libncurses.so.8 (0x802537000) libthr.so.3 => /lib/libthr.so.3 (0x80278c000) While most will probably prefer the default, I figured it would be nice to provide a means to use readline in case anyone wants that, since it already supports it. Please let me know if I'm misunderstanding something.
(In reply to Vidar Karlsen from comment #8) You are absolutely right, I totally misread your diff. Ok for me! Daniel
Meanwhile there's a new minor release, 2.4.2.
Created attachment 192680 [details] Tweak of the previous diff for 2.4.2
What's happening here? Do you need something else from me?
testbuilds@work
Can you provide an example on how to dump the data and how to re-import the data to pkg-message ?
testbuilds are fine.
(In reply to Kurt Jaeger from comment #14) Absolutely! It's in detail in the Changelog file. Daniel
I modified pkg-message. I'm a bit torn because pkg-message will be displayed after kc24 is installed, so it would be too late for the unlucky user. How difficult would it be to provide a dumpold-like command that reads old-style database files ? Well, in the pkg-tree one can go back by installing kc instead of kc24, but still...
Don't you have some means to display this before it gets installed?
A commit references this bug: Author: pi Date: Sat Jul 28 10:41:57 UTC 2018 New revision: 475519 URL: https://svnweb.freebsd.org/changeset/ports/475519 Log: New port: security/kc24 Console based password storing application using an encrypted XML document as its database. WWW: https://github.com/levaidaniel/kc Please read the UPDATING note! PR: 222376 Submitted by: Vidar Karlsen <vidar@karlsen.tech>, Daniel <leva@ecentrum.hu> (maintainer and upstream-author) Relnotes: https://github.com/levaidaniel/kc/blob/35656e47a36e96440eb5cc9e4f8a856856831e9a/Changelog Changes: head/UPDATING head/security/Makefile head/security/kc/Makefile head/security/kc24/ head/security/kc24/Makefile head/security/kc24/distinfo head/security/kc24/pkg-descr head/security/kc24/pkg-message
I'm not aware of any hook to display a pre-installation message. It's committed now, with some hints.
That's interesting. How do you handle eg. PostgreSQL upgrades to new, incompatible versions?
We cope with the UPDATING entries. It's not perfect, I'm aware.