DOCSLIB.ORG

Taxonomy of Package Management in Programming Languages and Operating Systems

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Taxonomy of Package Management in Programming Languages and Operating Systems Taxonomy of Package Management in Programming Languages and Operating Systems Hisham Muhammad Lucas C. Villa Real Michael Homer Kong Inc. IBM Research Victoria University of Wellington - [email protected] [email protected] Wellington, New Zealand [email protected] Abstract for node.js [3], a JavaScript environment. On a Mac system, Package management is instrumental for programming lan- the typical way to install command-line tools such as npm guages and operating systems, and yet it is neglected by both is via either Homebrew [4] or MacPorts [5], the two most areas as an implementation detail. For this reason, it lacks the popular general-purpose package managers for macOS. This same kind of conceptual organization: we lack terminology is not a deliberately contrived example; it is the regular way to classify them or to reason about their design trade-offs. In to install development modules for a popular language in a this paper, we share our experience in both OS and language- modern platform. specific package manager development, categorizing families The combinations of package managers change as we move of package managers and discussing their design implications to a different operating system or use a different language. beyond particular implementations. We also identify possibil- Learning one’s way through a new language or system, nowa- ities in the still largely unexplored area of package manager days, includes learning one or more packaging environments. interoperability. As a developer of modules, this includes not only using pack- age managers but also learning to deploy code using them, Keywords package management, operating systems, module which includes syntaxes for package specification formats, de- systems, filesystem hierarchy pendency and versioning rules and deployment conventions. Simply ignoring these environments and managing modules 1 Introduction and dependencies by hand is tempting, but the complexity Package managers are programs that map relations between of heterogeneous environments and keeping track of depen- files and packages (which correspond to sets of files), and dency updates can become burdensome — all these package between packages (dependencies), allowing users to perform managers were created to solve practical problems which maintenance of their systems in terms of packages rather than the developer would have to otherwise directly handle, after at the level of individual files. Package management is an all. Another alternative that is often proposed, especially by area that lies somewhere in the border between programming users of operating systems that feature a system-provided languages and operating systems: packaging is a step that package manager (as is the case of most Linux distributions), sits after a language’s build process, and before an operating is to avoid using multiple package managers and use a single system’s component installation. For this reason, it seems general-purpose package manager. This is, of course, as much to be overlooked by both fields as an implementation issue. of a solution as trying to make everyone agree on a single In the meantime, package management keeps growing in programming language — one of many analogies between complexity. New languages, new deployment models, and package management and programming languages. The result new portability requirements all give rise to new package is that the ecosystem is not getting any simpler, and at first management systems. Further, this is not simply a matter of glance it seems that package management is indeed a largely competing implementations: modern complex environments unsolved problem. often require several package managers to be used in tandem. However, maybe the statement “package management is For example, when writing JavaScript web applications on an unsolved problem” simply does not make sense, and is a Mac environment, a developer may require using Bower akin to saying that “programming languages are an unsolved [1], a package manager for client-side JavaScript compo- problem”. In the programming languages world we accept nents. Bower is installed using npm [2], a package manager that the multitude of languages is a given. Beyond that, we understand that there are families of languages with different PLOS ’19, October 27, 2019, Huntsville, ON, Canada paradigms, with well-known tradeoffs. We also accept that © 2019 Association for Computing Machinery. there is room for domain-specific languages (DSLs) and for This is the author’s version of the work. It is posted here for your personal use. Not for redistribution. The definitive Version of Record was published general-purpose languages. Most importantly, we know how in PLOS ’19: Workshop on Programming Languages and Operating Systems, to set boundaries for each language and how to make DSLs October 27, 2019, Huntsville, ON, Canada, https://doi.org/10.1145/3365137. and general-purpose languages interact. Most existing pack- 3365402. age management systems, however, are still oblivious to the PLOS ’19, October 27, 2019, Huntsville, ON, Canada Hisham Muhammad, Lucas C. Villa Real, and Michael Homer fact that they exist as part of a larger ecosystem, with parts of path that conforms to Python’s default directory for locally- it handled by other package managers. installed modules (e.g. /usr/lib/python3.7/site-pack- In this paper we draw on our own unique combination of ages/), whose definition predates the introduction of pip. experiences on all sides of this topic: developing a system- Database-oriented designs are often chosen when the package wide package manager for a Linux distribution [6, 7], creating manager needs to accomodate a pre-existing directory struc- a language-specific package manager [8], and integrating ture. If Python packages have modules with the same name, system and language-specific package managers [7], as well clashes may occur. In a filesystem-oriented design, such as for as being simply developers and end users of other software. example that of RubyGems, this problem would not happen. By building a taxonomy for package management and sharing Each package has its own subtree under a versioned directory, our experiences with package management development in and the rubygems.rb module, part of the default installation both the programming language and operating system spaces, of Ruby, takes care of finding the appropriate files when mod- we aim in this paper to frame the design choices, layers, ules are loaded with the require function. Figure 1 lists more and trade-offs attendant to package managers for developers, examples of package managers and their classification. maintainers, and users. The major trade-off between the filesystem-oriented and the database-oriented approaches is whether applications 2 Paradigms of package management: should be aware of the file structure defined by the man- filesystem-oriented vs. database-oriented ager or whether the manager should adapt to the file structure defined by applications. This affects how the manager tracks It is a typical didactic device to organize the landscape of the mapping of files and how applications are configured to programming languages into paradigms, such as imperative, find their resource files. functional, object-oriented, and so on. The paradigms a lan- In filesystem-oriented managers the mapping of files to guage is categorized into inform users about particular design packages is simple. File conflicts are naturally avoided by choices, and with these choices come design trade-offs. In storing files of different packages in separate subtrees. Ver- the world of package managers, we can also identify general sioning conflicts between variants of the same package can paradigms, by looking at their core concepts and design trade- also be handled via the tree structure. The structure also be- offs. Package managers map between files and packages, and comes more transparent to users, which can simplify their between packages and their dependencies, allowing users to experience. The run-time lookup of files by applications, how- perform maintenance of their systems in terms of packages ever, can be complicated, if they are oblivious to the structure rather than at the level of individual files. The central design defined by the package manager. Applications must either choice in a package manager, therefore, is how to perform agree beforehand to this structure (which might be an option those mappings. in domain-specific environments), or the package manager There are two approaches on how to map files to packages: has to do extra work to configure them to use the structure, the mapping can be based on the hierarchical directory struc- such as setting configuration options or environment variables, ture where the files reside, or can be separate. As this choice or in the worst case, patching them. embodies a series of trade-offs and is the single decision that Conversely, in database-oriented managers the mapping affects the design and implementation of a package manager of files to packages is more complicated. Applications may the most, we identify these as two paradigms of package install files wherever they please, and the package manager management. When the mapping is internal to the file hierar- needs to keep track. This includes handling potential conflicts chy structure, we say that package management is filesystem- if two packages want to use the same pathname. Database- oriented1. When it is external to the hierarchy of files being oriented systems will usually report on these conflicts and managed, the mapping needs to be stored elsewhere. We say forbid them. It is up to the integrator (such as a distribution in these cases that management is database-oriented. Most developer) who is building packages to resolve the conflict package managers for Linux distributions, such as RPM and somehow. Also, the package manager needs to verify that the dpkg/APT, are database-oriented. Filesystem-oriented pack- database and the contents of the filesystem remain in sync, age management is more often seen in language-specific pack- which is trivial in the filesystem-oriented approach.
Load more

Recommended publications
  • I Am Not Clueless Myths and Misconceptions About the Design Of
    I am not clueless or Myths and misconceptions about the design of GoboLinux Hisham H. Muhammad April 11, 2017 “Those who do not understand Unix are doomed to reinvent it, poorly.” – Henry Spencer, 1987 This week we had another release of GoboLinux, and again a number of people, even if indirectly, called me “clueless” for coming up with such a structure for a Linux distribution, for a number of reasons. None of those reasons was new; I heard all of them many times. This article is an attempt to sum them up, and explain why I chose the design decisions I made, hopefully clearing any pending misconceptions. I don’t have illusion this will prevent them keep happening, but at least I’ll have a text to point people to. This article ranges from common misconceptions from those who have never used GoboLinux, to well-intentioned but poorly-thought-out ideas that keep coming from time to time to the GoboLinux mailing list, often causing long debates. I’ll be separating the points in sections and they are meant to be self-contained, so feel free to skip directly to the ones that interest you, if you don’t feel like reading the whole thing. “There is a reason why things are the way they are” This is something I hear constantly, often followed by an explanation about the difference between /, /usr and /usr/local, and/or /bin and /sbin. I do understand the difference1. If I did away with this three-level distinction, is because I believe there are other ways to approach the problems this distinction tries to solve.
    [Show full text]
  • What If What I Need Is Not in Powerai (Yet)? What You Need to Know to Build from Scratch?
    IBM Systems What if what I need is not in PowerAI (yet)? What you need to know to build from scratch? Jean-Armand Broyelle June 2018 IBM Systems – Cognitive Era Things to consider when you have to rebuild a framework © 2017 International Business Machines Corporation 2 IBM Systems – Cognitive Era CUDA Downloads © 2017 International Business Machines Corporation 3 IBM Systems – Cognitive Era CUDA 8 – under Legacy Releases © 2017 International Business Machines Corporation 4 IBM Systems – Cognitive Era CUDA 8 Install Steps © 2017 International Business Machines Corporation 5 IBM Systems – Cognitive Era cuDNN and NVIDIA drivers © 2017 International Business Machines Corporation 6 IBM Systems – Cognitive Era cuDNN v6.0 for CUDA 8.0 © 2017 International Business Machines Corporation 7 IBM Systems – Cognitive Era cuDNN and NVIDIA drivers © 2017 International Business Machines Corporation 8 IBM Systems – Cognitive Era © 2017 International Business Machines Corporation 9 IBM Systems – Cognitive Era © 2017 International Business Machines Corporation 10 IBM Systems – Cognitive Era cuDNN and NVIDIA drivers © 2017 International Business Machines Corporation 11 IBM Systems – Cognitive Era Prepare your environment • When something goes wrong it’s better to Remove local anaconda installation $ cd ~; rm –rf anaconda2 .conda • Reinstall anaconda $ cd /tmp; wget https://repo.anaconda.com/archive/Anaconda2-5.1.0-Linux- ppc64le.sh $ bash /tmp/Anaconda2-5.1.0-Linux-ppc64le.sh • Activate PowerAI $ source /opt/DL/tensorflow/bin/tensorflow-activate • When you
    [Show full text]
  • Github: a Case Study of Linux/BSD Perceptions from Microsoft's
    1 FLOSS != GitHub: A Case Study of Linux/BSD Perceptions from Microsoft’s Acquisition of GitHub Raula Gaikovina Kula∗, Hideki Hata∗, Kenichi Matsumoto∗ ∗Nara Institute of Science and Technology, Japan {raula-k, hata, matumoto}@is.naist.jp Abstract—In 2018, the software industry giants Microsoft made has had its share of disagreements with Microsoft [6], [7], a move into the Open Source world by completing the acquisition [8], [9], the only reported negative opinion of free software of mega Open Source platform, GitHub. This acquisition was not community has different attitudes towards GitHub is the idea without controversy, as it is well-known that the free software communities includes not only the ability to use software freely, of ‘forking’ so far, as it it is considered as a danger to FLOSS but also the libre nature in Open Source Software. In this study, development [10]. our aim is to explore these perceptions in FLOSS developers. We In this paper, we report on how external events such as conducted a survey that covered traditional FLOSS source Linux, acquisition of the open source platform by a closed source and BSD communities and received 246 developer responses. organization triggers a FLOSS developers such the Linux/ The results of the survey confirm that the free community did trigger some communities to move away from GitHub and raised BSD Free Software communities. discussions into free and open software on the GitHub platform. The study reminds us that although GitHub is influential and II. TARGET SUBJECTS AND SURVEY DESIGN trendy, it does not representative all FLOSS communities.
    [Show full text]
  • Luarocks Fostering an Ecosystem of Lua Modules
    LuaRocks fostering an ecosystem of Lua modules Hisham Muhammad [email protected] @hisham_hm FOSDEM !"# $russels% $elgium &hat is LuaRocks 'ackage manager... like d(kg (a(t*get+% RPM% etc. like Ruby-ems, Python eggs, npm% C'/0% etc. ...for Lua e1tension modules written in Lua (.lua files) or ,inary modules (.so4.dll files) Fostering an ecosystem of Lua modules Some uni5ue challenges ...related to Lua as a language ...related to Lua as a community Lessons learned ...on building an ecosystem / one*slide introduction to Lua function process(filename, fn, ...) local f = io.open(filename) local rets = {} for line in f:lines() do rets[#rets+1] = { fn(line, ...) } end f:close() return rets end matches = process("file.txt", string.find, "foo") for i, match in ipairs(matches) do print(i, table.concat(match, ", ")) end / one*slide introduction to Lua function process(filename, fn, ...) local f = io.open(filename) local rets = {} o,6ects for line in f:lines() do rets[#rets+1] = { fn(line, ...) } end f:close() return rets end matches = process("file.txt", string.find, "foo") for i, match in ipairs(matches) do print(i, table.concat(match, ", ")) end / one*slide introduction to Lua function process(filename, fn, ...) local f = io.open(filename) local rets = {} for line in f:lines() do rets[#rets+1] = { fn(line, ...) } end f:close() return rets 3rst*class functions end matches = process("file.txt", string.find, "foo") for i, match in ipairs(matches) do print(i, table.concat(match, ", ")) end / one*slide introduction to Lua function process(filename, fn, ...)
    [Show full text]
  • Tarantool Выпуск 1.7.2
    Tarantool Выпуск 1.7.2 мар. 14, 2019 Оглавление 1 Что нового? 1 1.1 Что нового в Tarantool 1.7?....................................1 2 Общие сведения 2 2.1 Сервер приложений + СУБД...................................2 2.2 Возможности СУБД........................................3 3 Практикум 5 3.1 Практические задания на Lua..................................5 3.2 Практическое задание на C.................................... 17 4 Руководство пользователя 21 4.1 Предисловие............................................. 21 4.2 Начало работы........................................... 22 4.3 Функционал СУБД......................................... 25 4.4 Сервер приложений........................................ 58 4.5 Администрирование серверной части.............................. 72 4.6 Коннекторы............................................. 108 4.7 Вопросы и ответы......................................... 120 5 Справочники 121 5.1 Справочник по встроенной библиотеке............................. 121 5.2 Справочник по сторонним библиотекам............................. 228 5.3 Справочник по настройке..................................... 247 6 Руководство участника проекта 257 6.1 Справочник по C API....................................... 257 6.2 Детали реализации......................................... 280 6.3 Сборка и участие в проекте.................................... 293 6.4 Соглашения по разработке.................................... 298 Lua Module Index 329 i ГЛАВА 1 Что нового? Здесь собрана информация о существенных изменениях, которые
    [Show full text]
  • Introduction to Fmxlinux Delphi's Firemonkey For
    Introduction to FmxLinux Delphi’s FireMonkey for Linux Solution Jim McKeeth Embarcadero Technologies [email protected] Chief Developer Advocate & Engineer For quality purposes, all lines except the presenter are muted IT’S OK TO ASK QUESTIONS! Use the Q&A Panel on the Right This webinar is being recorded for future playback. Recordings will be available on Embarcadero’s YouTube channel Your Presenter: Jim McKeeth Embarcadero Technologies [email protected] | @JimMcKeeth Chief Developer Advocate & Engineer Agenda • Overview • Installation • Supported platforms • PAServer • SDK & Packages • Usage • UI Elements • Samples • Database Access FireDAC • Migrating from Windows VCL • midaconverter.com • 3rd Party Support • Broadway Web Why FMX on Linux? • Education - Save money on Windows licenses • Kiosk or Point of Sale - Single purpose computers with locked down user interfaces • Security - Linux offers more security options • IoT & Industrial Automation - Add user interfaces for integrated systems • Federal Government - Many govt systems require Linux support • Choice - Now you can, so might as well! Delphi for Linux History • 1999 Kylix: aka Delphi for Linux, introduced • It was a port of the IDE to Linux • Linux x86 32-bit compiler • Used the Trolltech QT widget library • 2002 Kylix 3 was the last update to Kylix • 2017 Delphi 10.2 “Tokyo” introduced Delphi for x86 64-bit Linux • IDE runs on Windows, cross compiles to Linux via the PAServer • Designed for server side development - no desktop widget GUI library • 2017 Eugene
    [Show full text]
  • Conda-Build Documentation Release 3.21.5+15.G174ed200.Dirty
    conda-build Documentation Release 3.21.5+15.g174ed200.dirty Anaconda, Inc. Sep 27, 2021 CONTENTS 1 Installing and updating conda-build3 2 Concepts 5 3 User guide 17 4 Resources 49 5 Release notes 115 Index 127 i ii conda-build Documentation, Release 3.21.5+15.g174ed200.dirty Conda-build contains commands and tools to use conda to build your own packages. It also provides helpful tools to constrain or pin versions in recipes. Building a conda package requires installing conda-build and creating a conda recipe. You then use the conda build command to build the conda package from the conda recipe. You can build conda packages from a variety of source code projects, most notably Python. For help packing a Python project, see the Setuptools documentation. OPTIONAL: If you are planning to upload your packages to Anaconda Cloud, you will need an Anaconda Cloud account and client. CONTENTS 1 conda-build Documentation, Release 3.21.5+15.g174ed200.dirty 2 CONTENTS CHAPTER ONE INSTALLING AND UPDATING CONDA-BUILD To enable building conda packages: • install conda • install conda-build • update conda and conda-build 1.1 Installing conda-build To install conda-build, in your terminal window or an Anaconda Prompt, run: conda install conda-build 1.2 Updating conda and conda-build Keep your versions of conda and conda-build up to date to take advantage of bug fixes and new features. To update conda and conda-build, in your terminal window or an Anaconda Prompt, run: conda update conda conda update conda-build For release notes, see the conda-build GitHub page.
    [Show full text]
  • Lightweight Virtualization with Gobolinux' Runner
    Lightweight virtualization with GoboLinux’ Runner Lucas C. Villa Real [email protected] About GoboLinux ● Alternative distribution born in 2002 ● Explores novel ideas in the Linux distribution ecosystem ● Introduces a rather diferent directory hierarchy How diferent? lucasvr@fedora ~] ls / bin dev home lib64 media opt root sbin sys usr boot etc lib lost+found mnt proc run srv tmp var lucasvr@fedora ~] ls /usr bin games include lib lib64 libexec local sbin share src tmp lucasvr@fedora ~] ls /usr/local bin etc games include lib lib64 libexec sbin share src lucasvr@gobolinux ~] ls / Data Mount Programs System Users GoboLinux File System Hierarchy /Programs Self-contained programs: no need for a package manager ~] ls /Programs AbsTk DifUtils GnuTLS Kerberos LibXML2 ACL Dit GoboHide Kmod LibXSLT Acpid DosFSTools GParted Lame Linux AGNClient E2FSProgs Gperf LCMS Linux-Firmware ALSA-Lib EFIBootMgr GPM Less Linux-PAM ALSA-Utils ELFUtils Grep LibDRM Lsof APR EncFS Grof LibEvdev Lua APR-Util ExFAT GRUB LibExif LuaRocks … /Programs Multiple versions of a given program can coexist ~] ls /Programs/GTK+ 2.24.22 2.24.30 3.10.6 3.21.4 Current Settings ~] ls /Programs/GTK+/2.24.22 bin doc include lib Resources share ~] ls /Programs/GTK+/2.24.22/bin gtk-builder-convert gtk-demo gtk-query-immodules2.0 gtk-update-icon-cache ~] ls /Programs/GTK+/2.24.30/bin gtk-builder-convert gtk-demo gtk-query-immodules2.0 gtk-update-icon-cache /Programs Easy to tell which fles belongs to which packages lucasvr@fedora ~] ls -l /bin/bash -rwxr-xr-x. 1 root root 1072008
    [Show full text]
  • Debian \ Amber \ Arco-Debian \ Arc-Live \ Aslinux \ Beatrix
    Debian \ Amber \ Arco-Debian \ Arc-Live \ ASLinux \ BeatriX \ BlackRhino \ BlankON \ Bluewall \ BOSS \ Canaima \ Clonezilla Live \ Conducit \ Corel \ Xandros \ DeadCD \ Olive \ DeMuDi \ \ 64Studio (64 Studio) \ DoudouLinux \ DRBL \ Elive \ Epidemic \ Estrella Roja \ Euronode \ GALPon MiniNo \ Gibraltar \ GNUGuitarINUX \ gnuLiNex \ \ Lihuen \ grml \ Guadalinex \ Impi \ Inquisitor \ Linux Mint Debian \ LliureX \ K-DEMar \ kademar \ Knoppix \ \ B2D \ \ Bioknoppix \ \ Damn Small Linux \ \ \ Hikarunix \ \ \ DSL-N \ \ \ Damn Vulnerable Linux \ \ Danix \ \ Feather \ \ INSERT \ \ Joatha \ \ Kaella \ \ Kanotix \ \ \ Auditor Security Linux \ \ \ Backtrack \ \ \ Parsix \ \ Kurumin \ \ \ Dizinha \ \ \ \ NeoDizinha \ \ \ \ Patinho Faminto \ \ \ Kalango \ \ \ Poseidon \ \ MAX \ \ Medialinux \ \ Mediainlinux \ \ ArtistX \ \ Morphix \ \ \ Aquamorph \ \ \ Dreamlinux \ \ \ Hiwix \ \ \ Hiweed \ \ \ \ Deepin \ \ \ ZoneCD \ \ Musix \ \ ParallelKnoppix \ \ Quantian \ \ Shabdix \ \ Symphony OS \ \ Whoppix \ \ WHAX \ LEAF \ Libranet \ Librassoc \ Lindows \ Linspire \ \ Freespire \ Liquid Lemur \ Matriux \ MEPIS \ SimplyMEPIS \ \ antiX \ \ \ Swift \ Metamorphose \ miniwoody \ Bonzai \ MoLinux \ \ Tirwal \ NepaLinux \ Nova \ Omoikane (Arma) \ OpenMediaVault \ OS2005 \ Maemo \ Meego Harmattan \ PelicanHPC \ Progeny \ Progress \ Proxmox \ PureOS \ Red Ribbon \ Resulinux \ Rxart \ SalineOS \ Semplice \ sidux \ aptosid \ \ siduction \ Skolelinux \ Snowlinux \ srvRX live \ Storm \ Tails \ ThinClientOS \ Trisquel \ Tuquito \ Ubuntu \ \ A/V \ \ AV \ \ Airinux \ \ Arabian
    [Show full text]
  • Luarocks Past, Present and Future
    LuaRocks past, present and future Hisham Muhammad Prologue: what is LuaRocks? ● A package manager for Lua modules ● Modules written in Lua (.lua), binary Lua modules (.so/.dll) and Lua scripts ● Usual features you would expect from a package manager ○ luarocks install <module> ○ luarocks remove <module> ○ ... Rocks and rockspecs ● Rock: a LuaRocks package ○ archive files (actually .zip files) ○ *.src.rock - contains source code ○ *.win32-x86.rock - “binary rock”, contains compiled binaries for a given platform ● Rockspec: a package specification file ○ A declarative Lua script, with rules on how to build and package rocks ○ *.rockspec - a Lua file containing some tables A rockspec Part I The past: a short history of LuaRocks Origins ● Kepler Project: research project to develop a platform for web development using Lua ○ combining modules that already existed (LuaSocket, CGILua) and adding the missing pieces ○ For more of the story, read Yuri Takhteyev’s book, “Coding Places” :) ● I started (re)writing Unix makefiles to automate the packaging/install process ● Common patterns emerged LuaRocks 0.x-1.x: a bumpy start ● 0.x was a gradual evolution ○ the goal for 1.0 was for it to be able to build all Kepler modules ● The rockspec format is unchanged since 1.0 ○ We really care about compatibility ○ Learning the format and writing a rockspec are not disposable efforts ● We got many things right, but we also got some of them wrong... Annoyances in LuaRocks 1.x ● LuaRocks 1.0 did not use the standard Lua layout for modules ○ It wasn’t clear that
    [Show full text]
  • Tarantool Выпуск 1.7.4
    Tarantool Выпуск 1.7.4 мар. 14, 2019 Оглавление 1 Что нового в Tarantool 1.7?2 2 What’s new in Tarantool 1.6.9 after February 15, 2017?4 3 What’s new in Tarantool 1.6?5 4 Общие сведения 6 4.1 Сервер приложений + СУБД...................................6 4.2 Возможности СУБД........................................7 5 Руководство пользователя8 5.1 Предисловие.............................................8 5.2 Начало работы...........................................9 5.3 Функционал СУБД......................................... 13 5.4 Сервер приложений........................................ 30 5.5 Администрирование серверной части.............................. 58 5.6 Репликация............................................. 76 5.7 Коннекторы............................................. 96 5.8 Вопросы и ответы......................................... 107 6 Справочники 109 6.1 Built-in modules reference..................................... 109 6.2 Справочник по сторонним библиотекам............................. 244 6.3 Справочник по настройке..................................... 263 6.4 Utility tarantoolctl .......................................... 280 6.5 Tips on Lua syntax......................................... 280 7 Практикум 282 7.1 Практические задания на Lua.................................. 282 7.2 Практическое задание на C.................................... 294 7.3 libslave tutorial........................................... 299 8 Contributor’s Guide 303 8.1 Справочник по C API....................................... 303 8.2 Internals..............................................
    [Show full text]
  • Conflict Resolution Via Containerless Filesystem Virtualization
    Dependency Heaven: Conflict Resolution via Containerless Filesystem Virtualization Anonymous Author(s) Abstract previous installation, effectively preventing concurrent ver- Resolving dependency versioning conflicts in applications sions of that library from coexisting. The same is true for is a long-standing problem in software development and packages whose executable names does not change across deployment. Containers have become a popular way to ad- releases; unless the user renames the existing executable dress this problem, allowing programs to be distributed in a files prior to the installation of a new version it is notpos- portable fashion and to run them under strict security con- sible to keep both installations around. The problem with straints. Due to the popularity of this approach, its use has that approach is that it breaks package managers, as the re- started to extend beyond its original aim, with users often named files will not be featured in the package manager’s creating containers bundling entire Linux distributions to database and, consequently, will not be tracked anymore. run mundane executables, incurring hidden performance Further, unless executables depending on the renamed files and maintenance costs. This paper presents an alternative are modified to reflect their new path, users need todefine approach to the problem of versioning resolution applied to which executable to activate at a given time, usually through locally-installed applications, through a virtualization tool tricky management of symbolic
    [Show full text]