create opsi repository

git-svn-id: https://svn.disconnected-by-peer.at/svn/linamh/trunk/opsi@2955 6952d904-891a-0410-993b-d76249ca496b
This commit is contained in:
geos_one 2011-06-23 01:19:42 +00:00
commit f32158b58f
9 changed files with 303 additions and 0 deletions

4
header.txt Normal file
View File

@ -0,0 +1,4 @@
# Copyright 1999-2009 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

8
profiles/package.mask Normal file
View File

@ -0,0 +1,8 @@
#####################################################################
# $Header: $
# When you add an entry to this file, add your name, the date, and an
# explanation of why something is getting masked
#
# NOTE: Please add your entry at the top!
#

1
profiles/repo_name Normal file
View File

@ -0,0 +1 @@
zarafa

6
profiles/use.desc Normal file
View File

@ -0,0 +1,6 @@
# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# Keep them sorted

9
profiles/use.local.desc Normal file
View File

@ -0,0 +1,9 @@
# Copyright 1999-2007 Gentoo Foundation.
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# This file contains descriptions of local USE flags, and the ebuilds which
# contain them.
# Keep it sorted.

5
sets.conf Normal file
View File

@ -0,0 +1,5 @@
[zarafa sets]
class = portage.sets.files.StaticFileSet
multiset = true
directory = ${repository:opsi}/sets/

67
skel.ChangeLog Normal file
View File

@ -0,0 +1,67 @@
# ChangeLog for <CATEGORY>/<PACKAGE_NAME>
# Copyright 1999-2009 Gentoo Foundation; Distributed under the GPL v2
# $Header: $
*<PACKAGE_NAME>-<PACKAGE_VERSION>-<PACKAGE_RELEASE> (DD MMM YYYY)
DD MMM YYYY; YOUR_NAME <YOUR_EMAIL> changed_file1, changed_file2 :
Initial import. Ebuild submitted by submitter_name <submitter_email>.
Note that the "changed_file" listing is optional if you are simply bumping
the rev of the ebuild and are only making changes to the .ebuild file
itself. Also note that we now have a single unified paragraph rather than
having the first line separated from the rest by a newline. Everything
should be in one block like this. (note by drobbins, 16 Jul 2002)
DD MMM YYYY; YOUR_NAME <YOUR_EMAIL> changed_file1, changed_file2: this is
an earlier ChangeLog entry.
-- Explanation of ChangeLog format:
***************************************************************************
THIS IS IMPORTANT: The ChangeLog format is a *chronological* account of all
changes made to a set of ebuilds. That means that the most recent ChangeLog
entry *always* goes at the top of the file. More explanation below.
***************************************************************************
***************************************************************************
ANOTHER IMPORTANT NOTE: There are some ChangeLogs that don't follow this
format and organize all changes under the "correct" "*" entry. This is not
correct. However, rather than making a concerted effort to fix these
ChangeLogs, we should spend our energy defining a comprehensive and strict
XML-based ChangeLog format which we then migrate to. But for any entries to
any ChangeLog that *you* make, please make sure to always add entries to the
top of the file like a good boy/girl. Even do this if it's clear that you're
adding an entry to a b0rked ChangeLog.
***************************************************************************
This changelog is targeted to users. This means that the comments should be
well explained and written in clean English.
Every new version or revision of the package should be marked by a '*'
separator line as above to indicate where in the chronology it was first
added to our CVS tree. Any changes since the last revision, really _any
changes at all_ have to be added to the top of the file, underneath the
initial copyright and cvs header comments, in exactly the same format as this
comment. If you are modifying older ebuilds, simply note them as changed
files and add your entry to the top of the ChangeLog. Resist the temptation
to "organize" your ChangeLog entries by placing them under the "correct" "*"
entries -- this isn't the purpose of the "*" entries.
This means that you start with header line that has the following format,
indented two spaces:
DD MMM YYYY; your_name <your_email> changed_file1, changed_file2: Your
explanation should follow. It should be indented and wrapped at a line width
of 80 characters. The changed_files can be omitted if they are obvious; for
example, if you are only modifying the .ebuild file and committing a new rev
of a package. Any details about what exactly changed in the code should be
added as a message when the changes are committed to cvs, not in this file.
-- A word regarding credit:
Please add credit information ("ebuild submitted by ...", "patch submitted
by ...") to the ChangeLog. Do not add this information to the ebuilds
themselves.
And remember: Give credit where credit is due. We're all doing this for
free, so the best we can hope (and expect!) to receive is credit.

169
skel.ebuild Normal file
View File

@ -0,0 +1,169 @@
# Copyright 1999-2009 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# NOTE: The comments in this file are for instruction and documentation.
# They're not meant to appear with your final, production ebuild. Please
# remember to remove them before submitting or committing your ebuild. That
# doesn't mean you can't add your own comments though.
# The 'Header' on the third line should just be left alone. When your ebuild
# will be committed to cvs, the details on that line will be automatically
# generated to contain the correct data.
# The EAPI variable tells the ebuild format in use.
# Defaults to 0 if not specified. The current PMS draft contains details on
# a proposed EAPI=0 definition but is not finalized yet.
# Eclasses will test for this variable if they need to use EAPI > 0 features.
# Ebuilds should not define EAPI > 0 unless they absolutely need to use
# features added in that version.
#EAPI=0
# inherit lists eclasses to inherit functions from. Almost all ebuilds should
# inherit eutils, as a large amount of important functionality has been
# moved there. For example, the $(get_libdir) mentioned below wont work
# without the following line:
inherit eutils
# A well-used example of an eclass function that needs eutils is epatch. If
# your source needs patches applied, it's suggested to put your patch in the
# 'files' directory and use:
#
# epatch ${FILESDIR}/patch-name-here
#
# eclasses tend to list descriptions of how to use their functions properly.
# take a look at /usr/portage/eclasses/ for more examples.
# Short one-line description of this package.
DESCRIPTION="This is a sample skeleton ebuild file"
# Homepage, not used by Portage directly but handy for developer reference
HOMEPAGE="http://foo.bar.com/"
# Point to any required sources; these will be automatically downloaded by
# Portage.
SRC_URI="ftp://foo.bar.com/${P}.tar.gz"
# License of the package. This must match the name of file(s) in
# /usr/portage/licenses/. For complex license combination see the developer
# docs on gentoo.org for details.
LICENSE=""
# The SLOT variable is used to tell Portage if it's OK to keep multiple
# versions of the same package installed at the same time. For example,
# if we have a libfoo-1.2.2 and libfoo-1.3.2 (which is not compatible
# with 1.2.2), it would be optimal to instruct Portage to not remove
# libfoo-1.2.2 if we decide to upgrade to libfoo-1.3.2. To do this,
# we specify SLOT="1.2" in libfoo-1.2.2 and SLOT="1.3" in libfoo-1.3.2.
# emerge clean understands SLOTs, and will keep the most recent version
# of each SLOT and remove everything else.
# Note that normal applications should use SLOT="0" if possible, since
# there should only be exactly one version installed at a time.
# DO NOT USE SLOT=""! This tells Portage to disable SLOTs for this package.
SLOT="0"
# Using KEYWORDS, we can record masking information *inside* an ebuild
# instead of relying on an external package.mask file. Right now, you should
# set the KEYWORDS variable for every ebuild so that it contains the names of
# all the architectures with which the ebuild works. All of the official
# architectures can be found in the keywords.desc file which is in
# /usr/portage/profiles/. Usually you should just set this to "~x86". The ~
# in front of the architecture indicates that the package is new and should be
# considered unstable until testing proves its stability. So, if you've
# confirmed that your ebuild works on x86 and ppc, you'd specify:
# KEYWORDS="~x86 ~ppc"
# Once packages go stable, the ~ prefix is removed.
# For binary packages, use -* and then list the archs the bin package
# exists for. If the package was for an x86 binary package, then
# KEYWORDS would be set like this: KEYWORDS="-* x86"
# DO NOT USE KEYWORDS="*". This is deprecated and only for backward
# compatibility reasons.
KEYWORDS="~x86"
# Comprehensive list of any and all USE flags leveraged in the ebuild,
# with the exception of any ARCH specific flags, i.e. "ppc", "sparc",
# "x86" and "alpha". This is a required variable. If the ebuild doesn't
# use any USE flags, set to "".
IUSE="gnome X"
# A space delimited list of portage features to restrict. man 5 ebuild
# for details. Usually not needed.
#RESTRICT="strip"
# Build-time dependencies, such as
# ssl? ( >=dev-libs/openssl-0.9.6b )
# >=dev-lang/perl-5.6.1-r1
# It is advisable to use the >= syntax show above, to reflect what you
# had installed on your system when you tested the package. Then
# other users hopefully won't be caught without the right version of
# a dependency.
DEPEND=""
# Run-time dependencies. Must be defined to whatever this depends on to run.
# The below is valid if the same run-time depends are required to compile.
RDEPEND="${DEPEND}"
# Source directory; the dir where the sources can be found (automatically
# unpacked) inside ${WORKDIR}. The default value for S is ${WORKDIR}/${P}
# If you don't need to change it, leave the S= line out of the ebuild
# to keep it tidy.
#S="${WORKDIR}/${P}"
src_compile() {
# Most open-source packages use GNU autoconf for configuration.
# The quickest (and preferred) way of running configure is:
econf || die "econf failed"
#
# You could use something similar to the following lines to
# configure your package before compilation. The "|| die" portion
# at the end will stop the build process if the command fails.
# You should use this at the end of critical commands in the build
# process. (Hint: Most commands are critical, that is, the build
# process should abort if they aren't successful.)
#./configure \
# --host=${CHOST} \
# --prefix=/usr \
# --infodir=/usr/share/info \
# --mandir=/usr/share/man || die "./configure failed"
# Note the use of --infodir and --mandir, above. This is to make
# this package FHS 2.2-compliant. For more information, see
# http://www.pathname.com/fhs/
# emake (previously known as pmake) is a script that calls the
# standard GNU make with parallel building options for speedier
# builds (especially on SMP systems). Try emake first. It might
# not work for some packages, because some makefiles have bugs
# related to parallelism, in these cases, use emake -j1 to limit
# make to a single process. The -j1 is a visual clue to others
# that the makefiles have bugs that have been worked around.
emake || die "emake failed"
}
src_install() {
# You must *personally verify* that this trick doesn't install
# anything outside of DESTDIR; do this by reading and
# understanding the install part of the Makefiles.
# This is the preferred way to install.
emake DESTDIR="${D}" install || die "emake install failed"
# When you hit a failure with emake, do not just use make. It is
# better to fix the Makefiles to allow proper parallelization.
# If you fail with that, use "emake -j1", it's still better than make.
# For Makefiles that don't make proper use of DESTDIR, setting
# prefix is often an alternative. However if you do this, then
# you also need to specify mandir and infodir, since they were
# passed to ./configure as absolute paths (overriding the prefix
# setting).
#emake \
# prefix="${D}"/usr \
# mandir="${D}"/usr/share/man \
# infodir="${D}"/usr/share/info \
# libdir="${D}"/usr/$(get_libdir) \
# install || die "emake install failed"
# Again, verify the Makefiles! We don't want anything falling
# outside of ${D}.
# The portage shortcut to the above command is simply:
#
#einstall || die "einstall failed"
}

34
skel.metadata.xml Normal file
View File

@ -0,0 +1,34 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd">
<!--
$Header: /var/cvsroot/gentoo-x86/skel.metadata.xml,v 1.18 2008/07/28 19:27:05 cardoe Exp $
This is the example metadata file.
The root element of this file is <pkgmetadata>. Within this element a
number of subelements are allowed: herd, maintainer, and
longdescription. herd is a required subelement.
For a full description look at:
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=4
Before committing, please remove the comments from this file. They are
not relevant for general metadata.xml files.
-->
<pkgmetadata>
<herd>no-herd</herd>
<maintainer>
<email>@gentoo.org</email>
<!-- <description>Description of the maintainership</description> -->
</maintainer>
<!-- <longdescription>Long description of the package</longdescription> -->
<!--
<use>
<flag name='flag'>Description of how USE='flag' affects this package</flag>
<flag name='userland_GNU'>Description of how USERLAND='GNU' affects this
package</flag>
<flag name='aspell'>Uses <pkg>app-text/aspell</pkg> for spell checking.
Requires an installed dictionary from <cat>app-dicts</cat></flag>
</use>
-->
</pkgmetadata>