
Clib: Package manager for C - petercooper
https://github.com/clibs/clib
======
pmahoney
Nice, but can anything challenge the "every language gets its own unique
package manager"? (And own unique build system for that matter).

~~~
StefanKarpinski
There is a natural break between system-level package management and language-
level package management. If you install language-level packages with system-
level package managers, then each language package needs to support every
single system-level package manager. E.g. you write a Ruby package and now you
have to support apt-get, yum, Gentoo, Arch, brew, MacPorts, etc. This is a
completely ridiculous situation to put language developers in, especially
since most language-level packages don't care what system they run on.

Instead, the best practice seems to be to install programming languages with
the system-level package manager and install the language's packages with the
language-level package manager. That way you only need one system-level
package per language, and each language-level package only needs to deal with
that language's package manager. The system package manager is responsible for
dealing with system-specific things while the language package manager is
responsible for language-specific things. It's a natural division.

It is conceivable that there could be a single cross-language, language-level
package manager. But what language would it be written in? And how would it
deal with the fact that each language uses different technologies and has
different approaches for installing and configuring libraries and packages?
When you think about it for a bit, I don't think it's so insensible for each
language to have its own package manager.

~~~
Hello71
> you write a Ruby package and now you have to support apt-get, yum, Gentoo,
> Arch, brew, MacPorts, etc

wrong. that's the package maintainer's job.

moreover, sensible package management systems have templates or libraries
(eclasses in Gentoo) to properly handle all kinds of packages.

all we ask for is that developers don't _actively break package management_ by
bundling _everything_ as is done here.

~~~
drewcrawford
Distro packages don't solve the needs of software developers. They solve the
need of distros, which are different (and conflicting) with the needs of
software developers. Therefore you will always have an eternal struggle
between language-level package managers who work for developers and system
ones that work for distros.

If there was some simple way to lob a tarball over the wall and get package
inclusion on Debian, Fedora, Gentoo, etc., then that would be one thing. In
reality however the number of random GitHub repos >> the number of package
maintainers. I know that Debian uses a variety of technical and social methods
to discourage new packages, and most people's software just isn't popular
enough to overcome those barriers, even if some of the reason they're not
popular is because they're not well-packaged (sort of a catch-22 there). Not
to mention people who install via apt or rpm are perpetually out of date.

Now compare that with pip or rubygems--one package to maintain, installs more-
or-less everywhere, accepts packages regardless of popularity, end users are
more often up-to-date. Better for software developers' problems in every
single dimension.

Sure that's bad for Fedora maintainers, but what are Fedora maintainers doing
for _me_?

~~~
Hello71
> Sure that's bad for Fedora maintainers, but what are Fedora maintainers
> doing for me?

ensuring a myriad of things that individual developers simply don't seem to
care about, ranging from simple testing to inter-package compatibility to
licensing to init scripts to old package cleanup to unbundling to...

------
michaelmior
It's a little scary for me that the source of available package is a wiki page
which is editable by anyone with a GitHub account.

~~~
lcampbell
Not only that, but there appear to be potential buffer overflows which involve
the data pulled from the wiki page[1]. I'm not sure why asprintf wasn't used
here (and in other places). The partial re-implementation of libc[2, 3] is
also somewhat frightening. As are potential unchecked integer overflows when
calculating a size to pass to malloc[4].

C is hard.

\--

[1] [https://github.com/clibs/clib/blob/master/src/clib-
install.c...](https://github.com/clibs/clib/blob/master/src/clib-
install.c#L86)

[2]
[https://github.com/clibs/clib/blob/master/deps/fs/fs.c](https://github.com/clibs/clib/blob/master/deps/fs/fs.c)

[3] [https://github.com/clibs/clib/blob/master/deps/str-
copy/str-...](https://github.com/clibs/clib/blob/master/deps/str-copy/str-
copy.c)

[4] [https://github.com/clibs/clib/blob/master/deps/http-
get/http...](https://github.com/clibs/clib/blob/master/deps/http-get/http-
get.c#L19)

~~~
gone35
Oh dear... I'm just sight-linting so this might be wrong, but I'm certain the
function _executable_ in src/clib-install.c [1] can be easily overflown by
providing a maliciously long package name or version --neither of which are
validated at all [2] despite coming straight from the wiki page, as you point
out. The function allocates 256-byte buffers to store a url and file name,
respectively, but blindly fills them up using _sprintf_ with non-validated
user-supplied data, and without checking the resulting number of characters
written, _eg_ :

    
    
      char *url = malloc(256);
      if(NULL == file) goto e1;
      sprintf(file,"%s-%s.tar.gz",pkg->name,pkg->version);
    

C is unforgiving indeed.

Also what's up with all those (0 == count) yoda conditionals all over? Is that
becoming a thing again?

[1] [https://github.com/clibs/clib/blob/master/src/clib-
install.c](https://github.com/clibs/clib/blob/master/src/clib-install.c)

[2] As far as I can tell, the package info from the wiki is dealt with by
functions in deps/clib-package.c that, despite promising names like
_json_object_get_string_safe_ , do not ever validate the provided name or
version string:

[https://github.com/clibs/clib/blob/master/deps/clib-
package/...](https://github.com/clibs/clib/blob/master/deps/clib-package/clib-
package.c)

------
giovannibajo1
I think this is missing half of the problem, that is connecting the package
with the build system. I know there is no "standard" build system for C, but
still. Go for instance does both; once you "go get" a package, it not only
downloads and pre-builds it, but makes sure that it is available for
transparent usage in your program.

I personally bias towards CMake, so I would appreciate a C package manager
which also makes sure that the package is included in my CMakeList.txt
somehow.

~~~
shoo
what if these are in fact two separate problems? then perhaps it is simpler to
solve them with separate tools instead of conflating them.

~~~
giovannibajo1
I can't see how it's simpler, because then you need to write N*M
bridges/connectors/plugins to let N package managers interact with M build
systems. And what if the library you download is meant to be built with a
build system which is different from the one you chose for your application?
What if you then want to globally turn on debugging or change a compilation
flag, or a preprocessor define to enable/disable a feature?

I don't know of any language-specific package manager that doesn't also make
the package immediately available to the programming environment without
further fiddling. Solving half of the problem... well, it's a half solution :)

------
oofabz
I love this if only because it highlights that package management is a hard
problem, still unsolved in even the most mature languages.

Package management is something that sounds really easy on the surface but
once you get into it you are overwhelmed with details, tradeoffs, and
drudgery. If we're ever going to solve it, we first need to acknowledge that
it's a very difficult problem.

------
gxc40
There is some overlap with CCAN
([http://ccodearchive.net/](http://ccodearchive.net/)).

------
cmbaus
This is a good idea. I could see this changing C development for the better.

------
null_ptr
I like this! Is it a sort of staging ground for libraries to eventually
graduate to various distributions' official repositories, or is it just random
bite-sized utilities for quick weekend projects?

------
chj
Can be a big time saver.

For any package manager to work painlessly and to scale, the repository must
be able to detect name conflicts on the code level.

------
Sir_Cmpwn
What ever happened to "apt-get" as the C package manager?

~~~
pjmlp
Doesn't work on AS/400, Windows, VxWorks, QNX, ...

~~~
panzi
And Fedora Linux.

