sqlite3, use PKGSPEC

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

sqlite3, use PKGSPEC

Stuart Henderson
yesterday I bumped the SHARED_LIBS version to enforce updates of sqlite
because some users have a tight check on build vs library version; on
reflection I think it would be simpler to set PKGSPEC so that an extra
step is not needed.

ok/comments?

Index: Makefile
===================================================================
RCS file: /cvs/ports/databases/sqlite3/Makefile,v
retrieving revision 1.100
diff -u -p -r1.100 Makefile
--- Makefile 28 Mar 2019 21:13:47 -0000 1.100
+++ Makefile 29 Mar 2019 10:58:59 -0000
@@ -2,17 +2,12 @@
 
 COMMENT= embedded SQL implementation
 
+V= 3.27.2
 DISTNAME = sqlite-autoconf-3270200
-PKGNAME= sqlite3-3.27.2
+PKGNAME= sqlite3-$V
 REVISION= 0
 
-# XXX needs bumps every time :-
 SHARED_LIBS +=  sqlite3                   37.5 # 8.6
-# sqlite suggests that users might like to assert() that library and header
-# versions match, so bumps are needed even if function signatures don't change.
-# ... at the current time the only one noticed is a < check (in subversion)
-# rather than an == check so minor bumps are enough to cope with this, though
-# we may run into others later.
 
 CATEGORIES= databases
 
@@ -24,6 +19,11 @@ PERMIT_PACKAGE_CDROM= Yes
 WANTLIB += c curses m pthread readline z
 
 MASTER_SITES = ${HOMEPAGE}2019/
+
+# enforce updates in dependent ports; sqlite suggests that code using the
+# library asserts that library and header versions are in sync - e.g.
+# subversion and mozilla have a < check, freeradius has an == check.
+PKGSPEC= sqlite3-=$V
 
 CONFIGURE_STYLE= gnu
 CONFIGURE_ARGS= --enable-editline \

Reply | Threaded
Open this post in threaded view
|

Re: sqlite3, use PKGSPEC

Jeremie Courreges-Anglas-2
On Fri, Mar 29 2019, Stuart Henderson <[hidden email]> wrote:
> yesterday I bumped the SHARED_LIBS version to enforce updates of sqlite
> because some users have a tight check on build vs library version;

Whining if the runtime lib is newer than expected looks plain useless to
me.  Printing a warning if the runtime lib is older may look nice.  But
*erroring out* ?!?

My opinion is that this pattern is wrong, that the advice given to
developers using sqlite[0] is wrong in the general case, and that
subversion should be fixed to not error out.

[0] https://www.sqlite.org/c3ref/libversion.html

--8<--
    Cautious programmers might include assert() statements in their
    application to verify that values returned by these interfaces match
    the macros in the header, and thus ensure that the application is
    compiled with matching library and header files.

      assert( sqlite3_libversion_number()==SQLITE_VERSION_NUMBER );
      assert( strncmp(sqlite3_sourceid(),SQLITE_SOURCE_ID,80)==0 );
      assert( strcmp(sqlite3_libversion(),SQLITE_VERSION)==0 );
-->8--

> on
> reflection I think it would be simpler to set PKGSPEC so that an extra
> step is not needed.
>
> ok/comments?

I find it is a too big hammer just because of what looks like a special
snowflake.  Ranting aside, I'd prefer if we kept your current solution,
ie bumping the minor version when upgrading sqlite.

> Index: Makefile
> ===================================================================
> RCS file: /cvs/ports/databases/sqlite3/Makefile,v
> retrieving revision 1.100
> diff -u -p -r1.100 Makefile
> --- Makefile 28 Mar 2019 21:13:47 -0000 1.100
> +++ Makefile 29 Mar 2019 10:58:59 -0000
> @@ -2,17 +2,12 @@
>  
>  COMMENT= embedded SQL implementation
>  
> +V= 3.27.2
>  DISTNAME = sqlite-autoconf-3270200
> -PKGNAME= sqlite3-3.27.2
> +PKGNAME= sqlite3-$V
>  REVISION= 0
>  
> -# XXX needs bumps every time :-
>  SHARED_LIBS +=  sqlite3                   37.5 # 8.6
> -# sqlite suggests that users might like to assert() that library and header
> -# versions match, so bumps are needed even if function signatures don't change.
> -# ... at the current time the only one noticed is a < check (in subversion)
> -# rather than an == check so minor bumps are enough to cope with this, though
> -# we may run into others later.
>  
>  CATEGORIES= databases
>  
> @@ -24,6 +19,11 @@ PERMIT_PACKAGE_CDROM= Yes
>  WANTLIB += c curses m pthread readline z
>  
>  MASTER_SITES = ${HOMEPAGE}2019/
> +
> +# enforce updates in dependent ports; sqlite suggests that code using the
> +# library asserts that library and header versions are in sync - e.g.
> +# subversion and mozilla have a < check, freeradius has an == check.
> +PKGSPEC= sqlite3-=$V
>  
>  CONFIGURE_STYLE= gnu
>  CONFIGURE_ARGS= --enable-editline \
>

--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Reply | Threaded
Open this post in threaded view
|

Re: sqlite3, use PKGSPEC

Stuart Henderson-6
On 2019/03/29 17:41, Jeremie Courreges-Anglas wrote:

> On Fri, Mar 29 2019, Stuart Henderson <[hidden email]> wrote:
> > yesterday I bumped the SHARED_LIBS version to enforce updates of sqlite
> > because some users have a tight check on build vs library version;
>
> Whining if the runtime lib is newer than expected looks plain useless to
> me.  Printing a warning if the runtime lib is older may look nice.  But
> *erroring out* ?!?
>
> My opinion is that this pattern is wrong, that the advice given to
> developers using sqlite[0] is wrong in the general case, and that
> subversion should be fixed to not error out.
>
> [0] https://www.sqlite.org/c3ref/libversion.html
>
> --8<--
>     Cautious programmers might include assert() statements in their
>     application to verify that values returned by these interfaces match
>     the macros in the header, and thus ensure that the application is
>     compiled with matching library and header files.
>
>       assert( sqlite3_libversion_number()==SQLITE_VERSION_NUMBER );
>       assert( strncmp(sqlite3_sourceid(),SQLITE_SOURCE_ID,80)==0 );
>       assert( strcmp(sqlite3_libversion(),SQLITE_VERSION)==0 );
> -->8--
>
> > on
> > reflection I think it would be simpler to set PKGSPEC so that an extra
> > step is not needed.
> >
> > ok/comments?
>
> I find it is a too big hammer just because of what looks like a special
> snowflake.  Ranting aside, I'd prefer if we kept your current solution,
> ie bumping the minor version when upgrading sqlite.

If it was just subversion then I'd consider patching that. But it's wider
and seems a bit silly to patch all over the place .. Looks like mozillas
have a hard exit in some cases -

  // Ensure that we are using the same version of SQLite that we compiled with
  // or newer.  Our configure check ensures we are using a new enough version
  // at compile time.
  if (SQLITE_VERSION_NUMBER > ::sqlite3_libversion_number()) {
    nsCOMPtr<nsIPromptService> ps(do_GetService(NS_PROMPTSERVICE_CONTRACTID));
    if (ps) {
      nsAutoString title, message;
      title.AppendLiteral("SQLite Version Error");
      message.AppendLiteral("The application has been updated, but the SQLite "
                            "library wasn't updated properly and the application "
                            "cannot run. Please try to launch the application again. "
                            "If that should still fail, please try reinstalling "
                            "it, or visit https://support.mozilla.org/.");
      (void)ps->Alert(nullptr, title.get(), message.get());
    }
    MOZ_CRASH("SQLite Version Error");
  }

- freeradius has a tighter dependency but at least is only a warning:

                if (sqlite3_libversion_number() != SQLITE_VERSION_NUMBER) {
                        WARN("rlm_sql_sqlite: libsqlite version changed since the server was built");
                        WARN("rlm_sql_sqlite: linked: %s built: %s", sqlite3_libversion(), SQLITE_VERSION);
                }