Difference between pages "User:Drobbins/Resume" and "Repository Configuration"

< User:Drobbins(Difference between pages)
 
(New repository layout)
 
Line 1: Line 1:
= Daniel Robbins =
+
{{Warning|This article is a work-in-progress referring to a future Portage version. It does not apply to the current Funtoo Portage version. Please do not update your configuration yet.}}
__NOEDITSECTION__
+
__NOTOC__
+
__NOTITLE__
+
== Profile ==
+
  
I am the creator of the Gentoo Linux operating system, an experienced architect of large-scale technology efforts, a strong Open Source project leader, a skilled software developer, and an accomplished technical writer.
+
Starting with Portage-2.3.8, a switch to a new repository configuration framework is complete and users may want to update their configuration files. This document aims to describe the goals for the new framework and how to use it.
  
I have made significant contributions at a number of organizations, including E*TRADE Financial and Microsoft Corporation. I have written many popular articles for IBM developerWorks and Intel Developer Services, and my writing has also appeared in C/C++ Users Journal.
+
== Multiple repository layout ==
 +
One of the most important changes is the switch from the old ''overlay'' layout to a new cleaner ''repository'' system. The new layout is more flexible and more predictable. For example, repositories can now use resources (eclasses, for example) provided by other repositories.
  
== Experience ==
+
The old layout was based on the concept of one ''main tree'' and optionally a number of overlays. The main tree provided base system ebuilds, eclasses, profiles, while overlays mostly were able to provide their own ebuilds. The ebuild provided by overlays overrode the ebuilds in main tree to the extend of making it impossible to install the main tree version. Overlays could also provide eclasses for their own ebuilds and package.* entries that applied to all overlays and to the main tree. The Package Manager is responsible for updating the main tree, while overlays are managed externally.
  
=== MediaWiki Consultant, WikiWorks; Jan 2014 - Present ===
+
The new layout is based on the concept of one or more configurable repositories. Each repository can either be stand-alone or depend upon other repositories. The distribution provides a repository called ''funtoo'' (a drop-in replacement for Gentoo's ''gentoo'' repository). Users can install more repositories at they will, the repositories providing their own ebuilds, eclasses and profiles as necessary and/or using them from other repositories. Users can explicitly choose the repository they want to install packages from. The Package Manager can update all repositories.
  
Expertise in deploying, developing and maintaining MediaWiki and Semantic MediaWiki. LDAP/Active Directory integration, MediaWiki extension development, Wiki farm architecture.
+
== Portage configuration ==
 +
=== New repository layout ===
 +
The repository configuration should be stored in <code>/etc/portage/repos.conf</code>. It can be either a single file or a directory containing one or more ''.conf'' files.
  
===Open Source Strategy Lead, Zenoss, Inc.; Austin, TX - Dec 2011 - Jan 2014 ===
+
The default configuration is installed as <code>/usr/share/portage/config/repos.conf</code>. This file is internal configuration file installed with portage ebuild and should '''not''' be modified. Instead, the configuration in <code>/etc/portage/repos.conf</code> can override the defaults specified there.
  
Led Open Source efforts, including Zenoss Core architecture, community management and Open Source
+
The configuration uses format similar to Windows .ini files. Each section heading (repository name in square brackets) signifies a single repository, followed by one or more key-value option pairs. For example, the following file copies default configuration for Funtoo repository:
release coordination. Architected new community infrastructure based on Semantic MediaWiki. Created
+
authoritative online catalog of all community ZenPacks. Created auto-build system for ZenPacks. Advised
+
Zenoss on Open Source and licensing issues and advanced Open Source initiatives throughout the company
+
  
===Senior Network and Application Performance Engineer, OPNET; Albuquerque, NM - Aug 2009 - Dec 2011 ===
+
{{file|name=/etc/portage/repos.conf/funtoo.conf|desc=Example configuration override for Funtoo repository|body=
Part of OPNET's Professional Services division. Sole developer and architect of an advanced, visual browser-based datacenter facilities and capacity management system for a large government agency with 1500+ servers and datacenters in multiple US locations. Integrated server utilization data from multiple sources. Delivered advanced reporting, planning and analysis capabilities to the organization.
+
[funtoo]
 +
# moved to non-default location!
 +
location = /var/db/repos/funtoo
 +
sync-type = git
 +
sync-uri = git://github.com/funtoo/ports-2015.git
 +
auto-sync = yes
 +
}}
 +
Location variable is now what used to be a PORTDIR, when using old-fashioned <code>/etc/portage/make.conf</code>.  <code>/var/db/repos/funtoo</code> is a dummy location example. Default location in Funtoo is  set to <code>/usr/portage</code>. Users are free to choose a location of their suits. sync-type is a CVS tree used for portage tree, git is a default in Funtoo. sync-uri is what used to be a SYNC variable, when using old-fashioned configuration through <code>/etc/portage/make.conf</code>
 +
The most useful repository configuration options are listed below:
 +
;location: ''Obligatory.'' Specifies the directory where repository is/will be stored. If Portage knows how to sync the repository and the location does not exist, it will be created on next ''emerge --sync''. Otherwise, the directory must exist.
 +
;priority: Specifies the priority used for ordering ebuilds from different repositories. If two repositories provide an ebuild with matching versions, the repository with higher priority will be used.
 +
;auto-sync: Specifies whether ''emerge --sync'' should update the repository. Defaults to ''yes'' if ''sync-type'' is specified, ''no'' otherwise.
 +
;sync-depth: Specifies ''--depth'' for git clone. Used only on initial sync. Defaults to 1. Can be set to 0 to force full clone (not pass ''--depth'' at all).
 +
;sync-type: Specifies syncing/update method. Can be one of: ''cvs'', ''git'', ''rsync'', ''svn''.
 +
;sync-umask: Specifies the umask used when updating/syncing the repository.
 +
;sync-uri: Specifies remote URI from which the repository will be cloned/synced. Can use any syntax valid for a particular syncing method.
 +
;sync-user: Specifies the user[:group] used to update/sync the repository. If ''FEATURES=usersync'' is used, defaults to the credentials of directory owner.
  
===President, Funtoo Technologies; Albuquerque, NM - 2006 to Present===
+
[[Category:Portage]]
Open Source consulting. Created Funtoo Linux, an advanced Gentoo Linux variant. Serving as Project Lead and responsible for managing Core development team. Implemented all core Funtoo technologies including Metro automated build system, automated git-based merge process, boot-update unified boot loader management system, and others.
+
 
+
===Senior Principal, E*TRADE Financial; Menlo Park, CA (remote) - Aug 2007 to June 2009===
+
Primary architect of E*TRADE’s virtualization strategy for development and production-focused workloads. Performed applied research and development related to virtual container build automation, high-performance virtualization and Open Source collaborative efforts. Participation in E*TRADE’s architectural review and standards development process.
+
 
+
===Vice President, Engineering, FSMLabs, Inc.; Socorro, NM - 2006 - 2007===
+
Architected the 5.0 release of FSMLabs RTLinuxPro hard real-time OS development kit with support for x86, x86-64, PowerPC, MIPS and ARM architectures. Designed a modern package management system for managing the FSMLabs user-space application stack, and updated cross-compiler tool chain. Created RTLinuxPro for Windows virtual machine runtime. Integrated open source RTSP/RTP streaming media (MPEG-2/4) stack into RTLinuxPro.
+
 
+
===Chief Technology Officer, ABC Coding Solutions; Albuquerque, NM - Jan 2006 - July 2006===
+
Architected, developed, and deployed a HIPAA-compliant Web-based medical billing application featuring support for CPT, HCPCS and the proposed ABC procedure code set. Performed extensive SQL Server 2000 to 2005 data migration work. Architected an encrypted XML-based data storage layer in C#/ASP.NET 2.0. Designed suite of ASP.NET 2.0 controls to utilize XML-based encrypted data storage layer. Integrated AJAX functionality into Web application and hardened application prior to deployment.
+
 
+
===Program Manager, Microsoft Corporation; Redmond, WA - 2005 to 2006===
+
Responsible for contributing to Microsoft’s Open Source/Shared Source strategy and overseeing the daily operations of Microsoft’s Linux lab. Technical responsibilities included overseeing competitive analysis and technical tear-downs, Linux/Windows interoperability testing, and intra-Microsoft educational efforts.
+
 
+
Contributed to Microsoft’s Shared Source licensing strategy. Tracked emerging Open Source trends and projects. Gained wide exposure to Microsoft technologies including Microsoft .NET, Windows Vista and Windows Vista device driver development. Met one-on-one with various technical luminaries throughout the company.
+
 
+
===Chief Architect, Gentoo Linux; Albuquerque, NM - 1999 to 2005===
+
Project Creator, Chief Architect and Project Lead of large, distributed international Gentoo development team. Architected all core Gentoo Linux technologies and tools including Portage, Gentoo’s dependency-based system initialization scripts, and catalyst, Gentoo's high-level automated release-building tool. Directed Gentoo Linux releases and all technology development. Authored all original Gentoo Linux documentation and designed XML/XSLT-based Web site. Designed all Gentoo artwork and logos. Established not-for-profit Gentoo Foundation, Inc. to serve as a container for all Gentoo Linux IP.
+
 
+
===Regular Columnist, IBM developerWorks, 2000 to 2003 ===
+
Author of critically acclaimed Linux and Unix-related technical articles geared towards developers and IT professionals.
+

Revision as of 13:52, February 14, 2015

Warning

This article is a work-in-progress referring to a future Portage version. It does not apply to the current Funtoo Portage version. Please do not update your configuration yet.

Starting with Portage-2.3.8, a switch to a new repository configuration framework is complete and users may want to update their configuration files. This document aims to describe the goals for the new framework and how to use it.

Multiple repository layout

One of the most important changes is the switch from the old overlay layout to a new cleaner repository system. The new layout is more flexible and more predictable. For example, repositories can now use resources (eclasses, for example) provided by other repositories.

The old layout was based on the concept of one main tree and optionally a number of overlays. The main tree provided base system ebuilds, eclasses, profiles, while overlays mostly were able to provide their own ebuilds. The ebuild provided by overlays overrode the ebuilds in main tree to the extend of making it impossible to install the main tree version. Overlays could also provide eclasses for their own ebuilds and package.* entries that applied to all overlays and to the main tree. The Package Manager is responsible for updating the main tree, while overlays are managed externally.

The new layout is based on the concept of one or more configurable repositories. Each repository can either be stand-alone or depend upon other repositories. The distribution provides a repository called funtoo (a drop-in replacement for Gentoo's gentoo repository). Users can install more repositories at they will, the repositories providing their own ebuilds, eclasses and profiles as necessary and/or using them from other repositories. Users can explicitly choose the repository they want to install packages from. The Package Manager can update all repositories.

Portage configuration

New repository layout

The repository configuration should be stored in /etc/portage/repos.conf. It can be either a single file or a directory containing one or more .conf files.

The default configuration is installed as /usr/share/portage/config/repos.conf. This file is internal configuration file installed with portage ebuild and should not be modified. Instead, the configuration in /etc/portage/repos.conf can override the defaults specified there.

The configuration uses format similar to Windows .ini files. Each section heading (repository name in square brackets) signifies a single repository, followed by one or more key-value option pairs. For example, the following file copies default configuration for Funtoo repository:

/etc/portage/repos.conf/funtoo.conf - Example configuration override for Funtoo repository
[funtoo]
# moved to non-default location!
location = /var/db/repos/funtoo
sync-type = git
sync-uri = git://github.com/funtoo/ports-2015.git
auto-sync = yes

Location variable is now what used to be a PORTDIR, when using old-fashioned /etc/portage/make.conf. /var/db/repos/funtoo is a dummy location example. Default location in Funtoo is set to /usr/portage. Users are free to choose a location of their suits. sync-type is a CVS tree used for portage tree, git is a default in Funtoo. sync-uri is what used to be a SYNC variable, when using old-fashioned configuration through /etc/portage/make.conf The most useful repository configuration options are listed below:

location
Obligatory. Specifies the directory where repository is/will be stored. If Portage knows how to sync the repository and the location does not exist, it will be created on next emerge --sync. Otherwise, the directory must exist.
priority
Specifies the priority used for ordering ebuilds from different repositories. If two repositories provide an ebuild with matching versions, the repository with higher priority will be used.
auto-sync
Specifies whether emerge --sync should update the repository. Defaults to yes if sync-type is specified, no otherwise.
sync-depth
Specifies --depth for git clone. Used only on initial sync. Defaults to 1. Can be set to 0 to force full clone (not pass --depth at all).
sync-type
Specifies syncing/update method. Can be one of: cvs, git, rsync, svn.
sync-umask
Specifies the umask used when updating/syncing the repository.
sync-uri
Specifies remote URI from which the repository will be cloned/synced. Can use any syntax valid for a particular syncing method.
sync-user
Specifies the user[:group] used to update/sync the repository. If FEATURES=usersync is used, defaults to the credentials of directory owner.