Created attachment 147380 [details] patch for freetds-msdblin-0.91.103 - Take maintainership
Patch looks good, over to Patch Ready
I would prefer to remove this port after committing the patch in bug 193686: - this is just one OPTION that can be enabled in freetds, so it looks like an obsolete port after the conversion to options ng - it can't be installed if freetds is already installed (so we would need CONFLICTS in both port Makefiles anyway) Objections?
I thought of removing it too. But unfortunately there are dependent ports. So CONFLICTS is the way we should follow. (In reply to Thomas Zander from comment #2) > I would prefer to remove this port after committing the patch in bug 193686: > - this is just one OPTION that can be enabled in freetds, so it looks like > an obsolete port after the conversion to options ng > - it can't be installed if freetds is already installed (so we would need > CONFLICTS in both port Makefiles anyway) > > Objections?
(In reply to Muhammad Moinur Rahman from comment #3) > I thought of removing it too. But unfortunately there are dependent ports. > So CONFLICTS is the way we should follow. Just to make sure I got this right (did some grepping and reading): 1) We have 10 ports that LIB_DEPENDS on libsybdb.so 2) Out of those, some say depend on freetds and some on freetds-msdblib 3) At least one (others as well?) is broken with freetds-msdblib Regarding 2) Do these explicitly require MSDBLIB? If so, how could the port ensure build requirements are met? There is only the dependency on libsybdb.so. What if freetds is already installed? The dependency will be satisfied and the build/link/run fail. Regarding 3) The sybtcl tarball has not changed in 14 years, so the project may be abandoned upstream and the problem will not go away. If this is the only one that is broken with msdblib, I'd say the best option is to work with the maintainer of sybtcl and get a patch to make this work with MSDBLIB, then remove the OPTION, make it default and retire the freetds-msdblib port. (It may be worth checking out other package repositories, e.g. from OpenBSD, pkgsrc or Gentoo, a fix may already exist.) Would you be able to check with the maintainer of sybctl? I added him to the CC list for this bug.
While going through the Makefile it's mentioned that sybctl relies on sybase style dblib. Now if we dig deeper there is a CONFIGURE_ARGS which is --enable-sybase-compat. So I will try to incorporate both the ARGS and check whether if sybctl builds. Will let you know at night. (In reply to Thomas Zander from comment #4) > (In reply to Muhammad Moinur Rahman from comment #3) > > I thought of removing it too. But unfortunately there are dependent ports. > > So CONFLICTS is the way we should follow. > > Just to make sure I got this right (did some grepping and reading): > 1) We have 10 ports that LIB_DEPENDS on libsybdb.so > 2) Out of those, some say depend on freetds and some on freetds-msdblib > 3) At least one (others as well?) is broken with freetds-msdblib > > Regarding 2) > Do these explicitly require MSDBLIB? If so, how could the port ensure build > requirements are met? There is only the dependency on libsybdb.so. What if > freetds is already installed? The dependency will be satisfied and the > build/link/run fail. > Regarding 3) > The sybtcl tarball has not changed in 14 years, so the project may be > abandoned upstream and the problem will not go away. If this is the only one > that is broken with msdblib, I'd say the best option is to work with the > maintainer of sybtcl and get a patch to make this work with MSDBLIB, then > remove the OPTION, make it default and retire the freetds-msdblib port. > (It may be worth checking out other package repositories, e.g. from OpenBSD, > pkgsrc or Gentoo, a fix may already exist.) > Would you be able to check with the maintainer of sybctl? I added him to the > CC list for this bug.
Port has been merged with the freetds port and removed from the tree.