DOCSLIB.ORG

Debian Packaging Tutorial

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Debian Packaging Tutorial Lucas Nussbaum [email protected] version 0.27 – 2021-01-08 Debian Packaging Tutorial 1 / 89 About this tutorial I Goal: tell you what you really need to know about Debian packaging I Modify existing packages I Create your own packages I Interact with the Debian community I Become a Debian power-user I Covers the most important points, but is not complete I You will need to read more documentation I Most of the content also applies to Debian derivative distributions I That includes Ubuntu Debian Packaging Tutorial 2 / 89 Outline 1 Introduction 2 Creating source packages 3 Building and testing packages 4 Practical session 1: modifying the grep package 5 Advanced packaging topics 6 Maintaining packages in Debian 7 Conclusions 8 Additional practical sessions 9 Answers to practical sessions Debian Packaging Tutorial 3 / 89 Outline 1 Introduction 2 Creating source packages 3 Building and testing packages 4 Practical session 1: modifying the grep package 5 Advanced packaging topics 6 Maintaining packages in Debian 7 Conclusions 8 Additional practical sessions 9 Answers to practical sessions Debian Packaging Tutorial 4 / 89 Debian I GNU/Linux distribution I 1st major distro developed “openly in the spirit of GNU” I Non-commercial, built collaboratively by over 1,000 volunteers I 3 main features: I Quality – culture of technical excellence We release when it’s ready I Freedom – devs and users bound by the Social Contract Promoting the culture of Free Software since 1993 I Independence – no (single) company babysitting Debian And open decision-making process (do-ocracy + democracy) I Amateur in the best sense: done for the love of it Debian Packaging Tutorial 5 / 89 Debian packages I .deb files (binary packages) I A very powerful and convenient way to distribute software to users I One of the two most common package formats (with RPM) I Universal: I 30,000 binary packages in Debian ! most of the available free software is packaged in Debian! I For 12 ports (architectures), including 2 non-Linux (Hurd; KFreeBSD) I Also used by 120 Debian derivative distributions Debian Packaging Tutorial 6 / 89 The Deb package format I .deb file: an ar archive $ ar tv wget_1.12-2.1_i386.deb rw-r--r-- 0/0 4 Sep 5 15:43 2010 debian-binary rw-r--r-- 0/0 2403 Sep 5 15:43 2010 control.tar.gz rw-r--r-- 0/0 751613 Sep 5 15:43 2010 data.tar.gz I debian-binary: version of the deb file format, "2.0\n" I control.tar.gz: metadata about the package control, md5sums, (pre|post)(rm|inst), triggers, shlibs,... I data.tar.gz: data files of the package I You could create your .deb files manually http://tldp.org/HOWTO/html_single/Debian-Binary-Package-Building-HOWTO/ I But most people don’t do it that way This tutorial: create Debian packages, the Debian way Debian Packaging Tutorial 7 / 89 Tools you will need I A Debian (or Ubuntu) system (with root access) I Some packages: I build-essential: has dependencies on the packages that will be assumed to be available on the developer’s machine (no need to specify them in the Build-Depends: control field of your package) I includes a dependency on dpkg-dev, which contains basic Debian-specific tools to create packages I devscripts: contains many useful scripts for Debian maintainers Many other tools will also be mentioned later, such as debhelper, cdbs, quilt, pbuilder, sbuild, lintian, svn-buildpackage, git-buildpackage,... Install them when you need them. Debian Packaging Tutorial 8 / 89 General packaging workflow Debian mirror Web upstream source apt-get source dget dh_make source package where most of the manual work is done debuild (build and test with lintian) or dpkg-buildpackage one or several binary packages .deb upload (dput) install (debi) Debian Packaging Tutorial 9 / 89 Example: rebuilding dash 1 Install packages needed to build dash, and devscripts sudo apt-get build-dep dash (requires deb-src lines in /etc/apt/sources.list) sudo apt-get install --no-install-recommends devscripts fakeroot 2 Create a working directory, and get in it: mkdir /tmp/debian-tutorial ; cd /tmp/debian-tutorial 3 Grab the dash source package apt-get source dash (This needs you to have deb-src lines in your /etc/apt/sources.list) 4 Build the package cd dash-* debuild -us -uc (-us -uc disables signing the package with GPG) 5 Check that it worked I There are some new .deb files in the parent directory 6 Look at the debian/ directory I That’s where the packaging work is done Debian Packaging Tutorial 10 / 89 Outline 1 Introduction 2 Creating source packages 3 Building and testing packages 4 Practical session 1: modifying the grep package 5 Advanced packaging topics 6 Maintaining packages in Debian 7 Conclusions 8 Additional practical sessions 9 Answers to practical sessions Debian Packaging Tutorial 11 / 89 Source package I One source package can generate several binary packages e.g. the libtar source generates the libtar0 and libtar-dev binary packages I Two kinds of packages: (if unsure, use non-native) I Native packages: normally for Debian specific software (dpkg, apt) I Non-native packages: software developed outside Debian I Main file: .dsc (meta-data) I Other files depending on the version of the source format I 1.0 or 3.0 (native): package_version.tar.gz I 1.0 (non-native): I pkg_ver.orig.tar.gz: upstream source I pkg_debver.diff.gz: patch to add Debian-specific changes I 3.0 (quilt): I pkg_ver.orig.tar.gz: upstream source I pkg_debver.debian.tar.gz: tarball with the Debian changes (See dpkg-source(1) for exact details) Debian Packaging Tutorial 12 / 89 Source package example (wget_1.12-2.1.dsc) Format: 3.0 (quilt) Source: wget Binary: wget Architecture: any Version: 1.12-2.1 Maintainer: Noel Kothe <[email protected]> Homepage: http://www.gnu.org/software/wget/ Standards-Version: 3.8.4 Build-Depends: debhelper (>> 5.0.0), gettext, texinfo, libssl-dev (>= 0.9.8), dpatch, info2man Checksums-Sha1: 50d4ed2441e67[..]1ee0e94248 2464747 wget_1.12.orig.tar.gz d4c1c8bbe431d[..]dd7cef3611 48308 wget_1.12-2.1.debian.tar.gz Checksums-Sha256: 7578ed0974e12[..]dcba65b572 2464747 wget_1.12.orig.tar.gz 1e9b0c4c00eae[..]89c402ad78 48308 wget_1.12-2.1.debian.tar.gz Files : 141461b9c04e4[..]9d1f2abf83 2464747 wget_1.12.orig.tar.gz e93123c934e3c[..]2f380278c2 48308 wget_1.12-2.1.debian.tar.gz Debian Packaging Tutorial 13 / 89 Retrieving an existing source package I From the Debian archive: I apt-get source package I apt-get source package=version I apt-get source package/release (You need deb-src lines in sources.list) I From the Internet: I dget url-to.dsc I dget http://snapshot.debian.org/archive/debian-archive/ 20090802T004153Z/debian/dists/bo/main/source/web/ wget_1.4.4-6.dsc (snapshot.d.o provides all packages from Debian since 2005) I From the (declared) version control system: I debcheckout package I Once downloaded, extract with dpkg-source -x file.dsc Debian Packaging Tutorial 14 / 89 Creating a basic source package I Download the upstream source (upstream source = the one from the software’s original developers) I Rename to <source_package>_<upstream_version>.orig.tar.gz (example: simgrid_3.6.orig.tar.gz) I Untar it I Rename the directory to <source_package>-<upstream_version> (example: simgrid-3.6) I cd <source_package>-<upstream_version> && dh_make (from the dh-make package) I There are some alternatives to dh_make for specific sets of packages: dh-make-perl, dh-make-php,... I debian/ directory created, with a lot of files in it Debian Packaging Tutorial 15 / 89 Files in debian/ All the packaging work should be made by modifying files in debian/ I Main files: I control – meta-data about the package (dependencies, etc.) I rules – specifies how to build the package I copyright – copyright information for the package I changelog – history of the Debian package I Other files: I compat I watch I dh_install* targets *.dirs, *.docs, *.manpages, . I maintainer scripts *.postinst, *.prerm, . I source/format I patches/ – if you need to modify the upstream sources I Several files use a format based on RFC 822 (mail headers) Debian Packaging Tutorial 16 / 89 debian/changelog I Lists the Debian packaging changes I Gives the current version of the package 1.2.1.1-5 Upstream Debian version revision I Edited manually or with dch I Create a changelog entry for a new release: dch -i I Special format to automatically close Debian or Ubuntu bugs Debian: Closes: #595268; Ubuntu: LP: #616929 I Installed as /usr/share/doc/package /changelog.Debian.gz mpich2 (1.2.1.1-5) unstable; urgency=low * Use /usr/bin/python instead of /usr/bin/python2.5. Allow to drop dependency on python2.5. Closes: #595268 * Make /usr/bin/mpdroot setuid. This is the default after the installation of mpich2 from source, too. LP: #616929 + Add corresponding lintian override. -- Lucas Nussbaum <[email protected]> Wed, 15 Sep 2010 18:13:44 +0200 Debian Packaging Tutorial 17 / 89 debian/control I Package metadata I For the source package itself I For each binary package built from this source I Package name, section, priority, maintainer, uploaders, build-dependencies, dependencies, description, homepage, . I Documentation: Debian Policy chapter 5 https://www.debian.org/doc/debian-policy/ch-controlfields Source: wget Section: web Priority: important Maintainer: Noel Kothe <[email protected]> Build-Depends: debhelper (>> 5.0.0), gettext, texinfo, libssl-dev (>= 0.9.8), dpatch, info2man Standards-Version: 3.8.4 Homepage: http://www.gnu.org/software/wget/ Package: wget Architecture: any Depends: ${shlibs:Depends}, ${misc:Depends} Description: retrieves files from the web
Recommended publications
  • Debian Developer's Reference Version 12.0, Released on 2021-09-01

    Debian Developer's Reference Version 12.0, Released on 2021-09-01

    Debian Developer’s Reference Release 12.0 Developer’s Reference Team 2021-09-01 CONTENTS 1 Scope of This Document 3 2 Applying to Become a Member5 2.1 Getting started..............................................5 2.2 Debian mentors and sponsors......................................6 2.3 Registering as a Debian member.....................................6 3 Debian Developer's Duties 9 3.1 Package Maintainer's Duties.......................................9 3.1.1 Work towards the next stable release............................9 3.1.2 Maintain packages in stable .................................9 3.1.3 Manage release-critical bugs.................................. 10 3.1.4 Coordination with upstream developers............................ 10 3.2 Administrative Duties.......................................... 10 3.2.1 Maintaining your Debian information............................. 11 3.2.2 Maintaining your public key.................................. 11 3.2.3 Voting.............................................. 11 3.2.4 Going on vacation gracefully.................................. 12 3.2.5 Retiring............................................. 12 3.2.6 Returning after retirement................................... 13 4 Resources for Debian Members 15 4.1 Mailing lists............................................... 15 4.1.1 Basic rules for use....................................... 15 4.1.2 Core development mailing lists................................. 15 4.1.3 Special lists........................................... 16 4.1.4 Requesting new
  • Linux Systems Administration and Security

    Linux Systems Administration and Security

    City University of New York (CUNY) CUNY Academic Works Open Educational Resources John Jay College of Criminal Justice 2020 Lecture - CSCI 275: Linux Systems Administration and Security Moe Hassan CUNY John Jay College NYC Tech-in-Residence Corps How does access to this work benefit ou?y Let us know! More information about this work at: https://academicworks.cuny.edu/jj_oers/27 Discover additional works at: https://academicworks.cuny.edu This work is made publicly available by the City University of New York (CUNY). Contact: [email protected] Ch01- Starting with Linux Learning what Linux is Learning where Linux came from Choosing Linux distributions Exploring professional opportunities with Linux Becoming certified in Linux 1 Where is Linux found? • Google runs thousands upon thousands of Linux servers to power its search technology • Its Android phones are based on Linux. • Facebook builds and deploys its site using what is referred to as a LAMP stack (Linux, Apache web server, MySQL database, and PHP web scripting language)—all open source projects. • Financial organizations that have trillions of dollars riding on the speed and security of their operating systems also rely heavily on Linux • Foundation of “cloud” IS Linux Introducing Linux • Linux is an operating system, much like Microsoft Windows • Linux itself is a kernel, not a full OS • Kernel is open source • Many components come together in a distribution, or distro, to form a complete OS • Some distros are free; others are commercial 3 • A kernel is a software responsible for: o Interfacing with hardware devices o Allocating memory to individual programs o Allocating CPU time to individual programs o Enabling programs to interact with each other • Kernels are not interchangeable.
  • Beginning Portable Shell Scripting from Novice to Professional

    Beginning Portable Shell Scripting from Novice to Professional

    Beginning Portable Shell Scripting From Novice to Professional Peter Seebach 10436fmfinal 1 10/23/08 10:40:24 PM Beginning Portable Shell Scripting: From Novice to Professional Copyright © 2008 by Peter Seebach All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage or retrieval system, without the prior written permission of the copyright owner and the publisher. ISBN-13 (pbk): 978-1-4302-1043-6 ISBN-10 (pbk): 1-4302-1043-5 ISBN-13 (electronic): 978-1-4302-1044-3 ISBN-10 (electronic): 1-4302-1044-3 Printed and bound in the United States of America 9 8 7 6 5 4 3 2 1 Trademarked names may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, we use the names only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. Lead Editor: Frank Pohlmann Technical Reviewer: Gary V. Vaughan Editorial Board: Clay Andres, Steve Anglin, Ewan Buckingham, Tony Campbell, Gary Cornell, Jonathan Gennick, Michelle Lowman, Matthew Moodie, Jeffrey Pepper, Frank Pohlmann, Ben Renow-Clarke, Dominic Shakeshaft, Matt Wade, Tom Welsh Project Manager: Richard Dal Porto Copy Editor: Kim Benbow Associate Production Director: Kari Brooks-Copony Production Editor: Katie Stence Compositor: Linda Weidemann, Wolf Creek Press Proofreader: Dan Shaw Indexer: Broccoli Information Management Cover Designer: Kurt Krames Manufacturing Director: Tom Debolski Distributed to the book trade worldwide by Springer-Verlag New York, Inc., 233 Spring Street, 6th Floor, New York, NY 10013.
  • Getestete Versionen Wine Debian Und Dessen Derivate (Ubuntu/Kubuntu/Xubuntu, Knoppix, Etc) Redhat, Fedora, Centos Opensuse Mandr

    Getestete Versionen Wine Debian Und Dessen Derivate (Ubuntu/Kubuntu/Xubuntu, Knoppix, Etc) Redhat, Fedora, Centos Opensuse Mandr

    Wie kann die MSR-Software unter Linux verwendet FAQ werden ? MSR Electronics GmbH Getestete Versionen Gentoo Linux 2.6.34 64-Bit Wine 1.3.3 MSR PC-Software V5.10.18 → VERSION Wine Für den Betrieb der MSR PC-Software unter Linux ist die Software Wine1 erforderlich. Diese muss zuerst installiert werden. Für die verschiedenen Linux Distributionen wird dies mittels ver­ schiedener Kommandos getan. Debian und dessen Derivate (Ubuntu/Kubuntu/Xubuntu, Knoppix, etc) Entweder die offiziellen Pakete der Distribution verwenden (oft veraltet): $ sudo apt-get install wine Oder die neusten Pakete der Wine Maintainer verwenden (empfohlen): $ sudo add-apt-repository ppa:ubuntu-wine/ppa $ sudo apt-get updates $ sudo apt-get install wine1.3 RedHat, Fedora, CentOS Wine sollte sich in den offiziellen Quellen befinden. $ sudo yum install wine die Option --enablerepo=updates-testing erzwingt die neuste Version aus dem testing Repository: openSUSE Mittels YaST2 oder yum (siehe RedHat). Eventuell lohnt es sich auch, die neuste Version vom openSUSE Build Server herunterzuladen respektive diesen einzubinden, siehe dazu auch die entsprechende Webseite2. Mandriva Offizielle Version: $ su $ urpmi wine oder neuste Version von der Sourceforge Seite3. Gentoo $ emerge wine 1 Wine Is Not an Emulator: ist eine Windows-kompatible Laufzeitumgebung für POSIX-kompatible Betriebssyste­ me. Mit Wine ist es möglich, viele Programme, die für die Microsoft-Windows-Betriebssysteme kompiliert wur­ den, auch unter Unix mit dem X Window System laufen zu lassen. 2 http://download.opensuse.org/repositories/Emulators:/Wine/ 3 http://sourceforge.net/projects/wine/files/Mandriva Packages/ Version 0.9 Draft 1/5 Wie kann die MSR-Software unter Linux verwendet FAQ werden ? MSR Electronics GmbH Eventuell funktionieren oben genannte Kommandos nicht unter allen Versionen der entspre­ chenden Distributionen.
  • Debian Installation Manual

    Debian Installation Manual

    Powered by Universal Speech Solutions LLC MRCP Deb Installation Manual Administrator Guide Revision: 70 Created: February 7, 2015 Last updated: March 15, 2021 Author: Arsen Chaloyan Powered by Universal Speech Solutions LLC | Overview 1 Table of Contents 1 Overview ............................................................................................................................................... 3 1.1 Applicable Versions ............................................................................................................ 3 1.2 Supported Distributions ...................................................................................................... 3 1.3 Authentication ..................................................................................................................... 3 2 Installing Deb Packages Using Apt-Get ............................................................................................... 4 2.1 Repository Configuration ................................................................................................... 4 2.2 GnuPG Key ......................................................................................................................... 4 2.3 Repository Update .............................................................................................................. 4 2.4 UniMRCP Client Installation .............................................................................................. 5 2.5 UniMRCP Server Installation ............................................................................................
  • Hydra: a Declarative Approach to Continuous Integration1

    Hydra: a Declarative Approach to Continuous Integration1

    Hydra: A Declarative Approach to Continuous Integration1 Eelco Dolstra, Eelco Visser Department of Software Technology, Faculty of Electrical Engineering, Mathematics and Computer Science (EWI), Delft University of Technology, The Netherlands Abstract There are many tools to support continuous integration: the process of automatically and con- tinuously building a project from a version management repository. However, they do not have good support for variability in the build environment: dependencies such as compilers, libraries or testing tools must typically be installed manually on all machines on which automated builds are performed. In this paper we present Hydra, a continuous build tool based on Nix, a package manager that has a purely functional language for describing package build actions and their dependencies. This allows the build environment for projects to be produced automatically and deterministically, and so significantly reduces the effort to maintain a continuous integration en- vironment. 1. Introduction Hydra is a tool for continuous integration testing and software release that uses a purely func- tional language to describe build jobs and their dependencies. Continuous integration (Fowler and Foemmel 2006) is a simple technique to improve the quality of the software development process. An automated system continuously or periodically checks out the source code of a project, builds it, runs tests, and produces reports for the developers. Thus, various errors that might accidentally be committed into the code base are automatically caught. Such a system allows more in-depth testing than what developers could feasibly do manually: • Portability testing: The software may need to be built and tested on many different plat- forms.
  • GNU Guix Cookbook Tutorials and Examples for Using the GNU Guix Functional Package Manager

    GNU Guix Cookbook Tutorials and Examples for Using the GNU Guix Functional Package Manager

    GNU Guix Cookbook Tutorials and examples for using the GNU Guix Functional Package Manager The GNU Guix Developers Copyright c 2019 Ricardo Wurmus Copyright c 2019 Efraim Flashner Copyright c 2019 Pierre Neidhardt Copyright c 2020 Oleg Pykhalov Copyright c 2020 Matthew Brooks Copyright c 2020 Marcin Karpezo Copyright c 2020 Brice Waegeneire Copyright c 2020 Andr´eBatista Copyright c 2020 Christine Lemmer-Webber Copyright c 2021 Joshua Branson Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled \GNU Free Documentation License". i Table of Contents GNU Guix Cookbook ::::::::::::::::::::::::::::::: 1 1 Scheme tutorials ::::::::::::::::::::::::::::::::: 2 1.1 A Scheme Crash Course :::::::::::::::::::::::::::::::::::::::: 2 2 Packaging :::::::::::::::::::::::::::::::::::::::: 5 2.1 Packaging Tutorial:::::::::::::::::::::::::::::::::::::::::::::: 5 2.1.1 A \Hello World" package :::::::::::::::::::::::::::::::::: 5 2.1.2 Setup:::::::::::::::::::::::::::::::::::::::::::::::::::::: 8 2.1.2.1 Local file ::::::::::::::::::::::::::::::::::::::::::::: 8 2.1.2.2 `GUIX_PACKAGE_PATH' ::::::::::::::::::::::::::::::::: 9 2.1.2.3 Guix channels ::::::::::::::::::::::::::::::::::::::: 10 2.1.2.4 Direct checkout hacking:::::::::::::::::::::::::::::: 10 2.1.3 Extended example ::::::::::::::::::::::::::::::::::::::::
  • Oracle Berkeley DB Installation and Build Guide Release 18.1

    Oracle Berkeley DB Installation and Build Guide Release 18.1

    Oracle Berkeley DB Installation and Build Guide Release 18.1 Library Version 18.1.32 Legal Notice Copyright © 2002 - 2019 Oracle and/or its affiliates. All rights reserved. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. Berkeley DB, and Sleepycat are trademarks or registered trademarks of Oracle. All rights to these marks are reserved. No third- party use is permitted without the express prior written consent of Oracle. Other names may be trademarks of their respective owners. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.
  • Application of Bagit-Serialized Research Object Bundles for Packaging and Re-Execution of Computational Analyses

    Application of Bagit-Serialized Research Object Bundles for Packaging and Re-Execution of Computational Analyses

    Application of BagIt-Serialized Research Object Bundles for Packaging and Re-execution of Computational Analyses Kyle Chard Bertram Ludascher¨ Thomas Thelen Computation Institute School of Information Sciences NCEAS University of Chicago University of Illinois at Urbana-Champaign University of California at Santa Barbara Chicago, IL Champaign, IL Santa Barbara, CA [email protected] [email protected] [email protected] Niall Gaffney Jarek Nabrzyski Matthew J. Turk Texas Advanced Computing Center Center for Research Computing School of Information Sciences University of Texas at Austin University of Notre Dame University of Illinois at Urbana-Champaign Austin, TX South Bend, IN Champaign, IL [email protected] [email protected] [email protected] Matthew B. Jones Victoria Stodden Craig Willisy NCEAS School of Information Sciences NCSA University of California at Santa Barbara University of Illinois at Urbana-Champaign University of Illinois at Urbana-Champaign Santa Barbara, CA Champaign, IL Champaign, IL [email protected] [email protected] [email protected] Kacper Kowalik Ian Taylor yCorresponding author NCSA Center for Research Computing University of Illinois at Urbana-Champaign University of Notre Dame Champaign, IL South Bend, IN [email protected] [email protected] Abstract—In this paper we describe our experience adopting and can be used for verification of computational reproducibil- the Research Object Bundle (RO-Bundle) format with BagIt ity, for example as part of the peer-review process. serialization (BagIt-RO) for the design and implementation of Since its inception, the Whole Tale platform has been “tales” in the Whole Tale platform. A tale is an executable research object intended for the dissemination of computational designed to bring together existing open science infrastructure.
  • Increasing Automation in the Backporting of Linux Drivers Using Coccinelle

    Increasing Automation in the Backporting of Linux Drivers Using Coccinelle

    Increasing Automation in the Backporting of Linux Drivers Using Coccinelle Luis R. Rodriguez Julia Lawall Rutgers University/SUSE Labs Sorbonne Universites/Inria/UPMC/LIP6´ [email protected] [email protected] [email protected], [email protected] Abstract—Software is continually evolving, to fix bugs and to a kernel upgrade. Upgrading a kernel may also require add new features. Industry users, however, often value stability, experience to understand what features to enable, disable, or and thus may not be able to update their code base to the tune to meet existing deployment criteria. In the worst case, latest versions. This raises the need to selectively backport new some systems may rely on components that have not yet been features to older software versions. Traditionally, backporting has merged into the mainline Linux kernel, potentially making it been done by cluttering the backported code with preprocessor impossible to upgrade the kernel without cooperation from the directives, to replace behaviors that are unsupported in an earlier version by appropriate workarounds. This approach however component vendor or a slew of partners that need to collaborate involves writing a lot of error-prone backporting code, and results on developing a new productized image for a system. As an in implementations that are hard to read and maintain. We example, development for 802.11n AR9003 chipset support consider this issue in the context of the Linux kernel, for which on the mainline ath9k device driver started on March 20, older versions are in wide use. We present a new backporting 2010 with an early version of the silicon, at which point the strategy that relies on the use of a backporting compatability most recent major release of the Linux kernel was v2.6.32.
  • Contributor's Guidelines

    Contributor's Guidelines

    Contributor’s Guidelines Release 17.11.10 Feb 27, 2020 CONTENTS 1 DPDK Coding Style1 1.1 Description.......................................1 1.2 General Guidelines..................................1 1.3 C Comment Style...................................1 1.4 C Preprocessor Directives..............................2 1.5 C Types.........................................4 1.6 C Indentation......................................7 1.7 C Function Definition, Declaration and Use.....................9 1.8 C Statement Style and Conventions......................... 11 1.9 Python Code...................................... 13 2 Design 14 2.1 Environment or Architecture-specific Sources.................... 14 2.2 Library Statistics.................................... 15 2.3 PF and VF Considerations.............................. 16 3 Managing ABI updates 18 3.1 Description....................................... 18 3.2 General Guidelines.................................. 18 3.3 What is an ABI..................................... 18 3.4 The DPDK ABI policy................................. 19 3.5 Examples of Deprecation Notices.......................... 20 3.6 Versioning Macros................................... 20 3.7 Setting a Major ABI version.............................. 21 3.8 Examples of ABI Macro use............................. 21 3.9 Running the ABI Validator............................... 25 4 DPDK Documentation Guidelines 27 4.1 Structure of the Documentation........................... 27 4.2 Role of the Documentation.............................
  • 2004 USENIX Annual Technical Conference

    2004 USENIX Annual Technical Conference

    USENIX Association Proceedings of the FREENIX Track: 2004 USENIX Annual Technical Conference Boston, MA, USA June 27–July 2, 2004 © 2004 by The USENIX Association All Rights Reserved For more information about the USENIX Association: Phone: 1 510 528 8649 FAX: 1 510 548 5738 Email: [email protected] WWW: http://www.usenix.org Rights to individual papers remain with the author or the author's employer. Permission is granted for noncommercial reproduction of the work for educational or research purposes. This copyright notice must be included in the reproduced paper. USENIX acknowledges all trademarks herein. The NetBSD Update System Alistair Crooks, The NetBSD Project 9th April 2004 Abstract driving force behind the use of pkgsrc or NetBSD - rather, this is a description of a facility which is This paper explains the needs for a binary patch and used in NetBSD and which can be used on any other update system, and explains the background and im- operating system to augment the standard facilities plementation of NetBSD-update, a binary update fa- which are in place. cility for NetBSD. The implementation is then anal- ysed, and some lessons drawn for others who may be interested in implementing their own binary up- Driving Forces for a Binary Patch and date system using the NetBSD pkgsrc tools, which Update System are available for many operating systems and envi- ronments already. It is now common to nd rewalls in large and small organisations, preventing malign access, and protect- ing the organisation from intrusion and other attacks. The NetBSD Binary Update Sys- It would not be prudent to have a C compiler in- tem stalled on such a machine - its use should be that of a gatekeeper, as a bouncer with an attitude, keep- Unix, Linux and the BSD operating systems have ing anything suspicious out, and not allowing anyone traditionally been distributed in source format, and who does manage to penetrate the defences to use users and administrators have had a long tradition any tools to break further into the infrastructure.