| Wherewith do you teach tomorrow?
|
Currently we built all packages on the media in the openSUSE Buildservice following the SUSE Build Tutorial and the Build Service Tutorial. So everyone who wants to help us packaging needs a buildservice account first.
Afterwards you can write an email to Lars or the mailinglist and we'll add you as maintainer of your package in the openSUSE-Education Buildservice Repository.
Contents |
We enhance the general Packaging Guidelines and Conventions a bit for packages in the Education repositories.
Vendor: openSUSE-Educationto your specfile. So zypper knows that this package comes from the same vendor as all other packages and allows updating this package. This includes some kind of "quality" for our packages. We add this string to trustedVendors (for details see Bug 186636) so our packages are unlocked and can be updated later.
Add a description in the openSUSE wiki. We use a special template] so users can find education packages easily.
%description
[...]
Author(s):
-------------
Name <email>
 | You can find a list of possible Menu Categories here. |
openSUSE uses a special macro to handle entries in the desktop menues. Please refer to "The packaging guideline" for details. This is just a short enhancement of this description.
openSUSE uses a special way to handle translations in desktop files:
This allows openSUSE to:
Problems:
%if 0%{?suse_version}
%suse_update_desktop_file -n %{name}
%endif
%changelogtag in your specfile to be consistent with the general RPM guidelines. But for some later enhancements (packaging also debian packages), it is necessary to have the changes of a package in a separate file. The buildservice already handles this files automatically, if the %changelog entry in the specfile is empty and a file named echo $(basename *.spec .spec).changes is present. (So for example: you have a specfile called mypackage.spec and a changelog file called mypackage.changes). The format of this mypackage.changes is
------------------------------------------------------------------- Tue Apr 22 20:54:26 CEST 2008 - your@email.com -
If you like, you can use this small script to produce a changelog entry like above.
Just save this script, give him execute rights (chmod +x), change the email-Variable and call it with the name of the specfile.
Other important notes about the changelog entries:
Build "ready to use packages" in the Education Repositories. Means: normally you like to "develop" a package by changing it's specfile, adding scripts, updating the tarball and so on. As the Education repositories should always in an installable state, this development would perhaps break the installation for endusers. So you have two options here:
You need packages from other repositories? Thats a real problem, hugh! Two options here:
Don't know where to start? Don't know which package interests most of our users?
Have a look at the wishlist and try to build a package from this list in the buildservice. Please: don't create just a new package without any content than the source and the pseudo specfile. We expect that a user who creates a new package will work on it until he is finished...
Also: Please Login and assign the related "bugreport" to your account, so other people (means: even the requester) knows that you start working on the package. Give the requester a warm "Welcome Message" in the bugreport and inform him that you start working on the package. Ask him to test your new package - we neeed feedback from our "customers".
© 2009 Novell, Inc. All Rights Reserved.
