LuaNotify contains two different packages

[LionOps]

The most recent version of LuaNotify is an entirely different package than what the module is described as being. You can see here that LuaNotify is a "Lua package providing tools for implementing observer programming pattern." but the latest publish is a binding for libnotify.

The fact that there are two completely different packages under the same namespace is worrisome for security reasons too. People could install a malicious module over the intended one.

Here are the relevant rockspecs.

LuaNotify0.1-1 rockspec:

package = "LuaNotify"
version = "0.1-1"
source = {
   url = "http://github.com/downloads/katcipis/luanotify/luanotify-0.1.tar.gz"
}
description = {
   summary = "Lua package providing tools for implementing observer programming pattern",
   detailed = [[
       LuaNotify is inspired on many libraries that do event dispatching, like py-notify, GSignals, QT event system, wxWidgets event system, etc. But we tried to do something different that can make use of Lua resources and to be more Lua-ish as possible.
   ]],
   homepage = "http://github.com/katcipis/luanotify", 
   license = "LGPL" 
}
dependencies = {
   "lua >= 5.1"
}

build = {
   type = "builtin",
   modules = {
      ["notify.double_queue"] = "notify/double_queue.lua",
      ["notify.event"]        = "notify/event.lua",
      ["notify.signal"]       = "notify/signal.lua"
   }
}

LuaNotify 0.2-1 rockspec:

package = "luanotify"
version = "0.2-1"
source = {
   url = "http://w3.impa.br/~gabrield/code/luanotify/luanotify-0.2-1.tar.gz",
   dir = "luanotify",
}
description = {
   summary = "Simple bind from libnotify to Lua.",
   detailed = [[
	Simple library binding libnotify to Lua, quite easy
	to use, supporting emergency levels. Pop up notifications
	from Lua to your desktop now is a piece of cake.
   ]],
   homepage = "http://w3.impa.br/~gabrield/code/luanotify/",
   license = "MIT/X11"
}

dependencies = {
   "lua >= 5.1"
}

external_dependencies = {
   NOTIFY = {
      header = "libnotify/notify.h",
   }
}

build= {
   type = "make",
   install_pass = false,
   build_variables = {
--      CFLAGS = "$(CFLAGS)",
      LUAINC = "$(LUA_INCDIR)",
      LUALIB = "$(LUA_LIBDIR)",
      LUABIN = "$(LUA_BINDIR)",
      LIBS   = "-lnotify -L$(NOTIFY_LIBDIR)",
      INCS   = "-I$(LUA_INCDIR) -I$(NOTIFY_INCDIR)",
      LIBFLAG = "$(LIBFLAG)"
   },
   install = {
      lib = { "notify.so" },
   },
}

[hishamhm]

@DevShep these entries are still assigned to the catch-all luarocks account, meaning they were never claimed since the LuaRocks repository moved to the current luarocks.org website many years ago.

Are you maintaining any of these packages or are in touch with their maintainers? Names in the current incarnation of luarocks.org are first-come first-served: if any maintainer comes forward, we can assign the manifest entry to their account.

Fortunately, it seems no other packages specify luanotify as dependencies so fixing this should be possible without too much hassle if we can establish which repo this name should be pointing to. In any case, 0.2 (the libnotify bindings) has been the default version returned by luarocks.org for many years now, but its original URL is no longer available — given that it's a user account from a university, it's quite possible that the author moved on and the project is orphaned.

[LionOps]

Are you maintaining any of these packages or are in touch with their maintainers? No, unfortunately. It may be possible to get in touch with the original package maintainer as there is a public GitHub for the code, though.

I don't have a strong preference for how this gets resolved other than that it does. Granting either a new namespace, such as luaLibNotify, may work, but I'd prefer to defer to people who are more involved and understand any implications with such a change. If it's possible to flag packages as abandoned or deprecated, perhaps deprecate luaNotify and give each a new name?

Thanks for your timely response!