The goal of Togo is not to try to accommodate a potentially unlimited number of use cases (that will only continue to expand as new languages and deployment systems are developed), but rather to create a "well defined" set of practices and a standardized build environment for RPM development so that most software may be bundled into an RPM with minimal changes to how it is done.
Utilizing one tool to convert perl modules, another to convert ruby gems, another to convert python eggs, and yet another to package home-grown software is not the answer. There is no magic tool that will handle all cases, nor should we try to create one. -but I digress.
My intention is to make the process of understanding and creating an RPM easier so that the authors of such disparate software modules may create RPMs instead of (or in addition to) their
proprietary formats - something which is often avoided because of the added complexity involved with creating an RPM using existing tools and documentation.
By making the system easy enough for beginners to understand and use, and powerful enough to handle
more complex packages, we can introduce a level of build standardization and good practices by including them in the software.
There are several steps that any RPM author needs to take, regardless of whether the process is done manually or is automated by some
tool:
1) Configure/create your build environment and directory structure
2) Tar your source files and place them in the above-mentioned directory structure
3) Create and configure your spec file to match your build environment and link your sources
-all Togo attempts to do is perform those steps in a sane, organized manner that accommodates the majority of use cases out there, with a heavy focus on re-usability.
The bottom line is that, for years, it's been too difficult for people to make simple RPMs of custom software. A sys-admin should be able to take his shell script, package
it up, and deploy it to a yum repo within a couple of minutes from start to finish.
Togo provides those people with a solution that will allow them to bundle their software into LSB-compliant packages,
using a standardized set of practices, with a minimal amount of work on their part.
To spell out what I'm looking for, I want feedback on how people package their software relative to the way togo does it.
- Do you use a standardized build structure? If yes, what does it look like and why is it organized that way?
- Do your find yourself using a different %build/%install section for every RPM you create? Why?
- What types of software do you typically package? Compiled? Interpreted scripts?
Thanks,
-Gene
On Tuesday, January 28, 2014 10:42 PM, Nico Kadel-Garcia <nkadel@xxxxxxxxx> wrote:
The reason cpanspec and cpan2rpm work so well is because CPAN source
bundles have a well defined format, and doesn't accept packages that
don't follow those standards. Other packages often fail to follow
those. The inconsistencies between, for example, FSF packages, Apache
packages, Ruby gems, PHP modules, etc., etc. all have distinct basic
formats. Do not get me *started* on various Google "summer of code"
packages, and the abuse that X based packages, all of Dan Bernstein's
software such as djbdns and daemontools and qmail, and the rare
cunning and misnaming of old tols like RT. Just..... don't get me
started, we'll be here all day.
So unless you want to spend hundreds of hours trying to maintain a
growing bundle of exceeption handling, I really urge you to start from
one that woks well, such as the actively maintained cpanspec, and
expand it rather than starting from scratch.
bundles have a well defined format, and doesn't accept packages that
don't follow those standards. Other packages often fail to follow
those. The inconsistencies between, for example, FSF packages, Apache
packages, Ruby gems, PHP modules, etc., etc. all have distinct basic
formats. Do not get me *started* on various Google "summer of code"
packages, and the abuse that X based packages, all of Dan Bernstein's
software such as djbdns and daemontools and qmail, and the rare
cunning and misnaming of old tols like RT. Just..... don't get me
started, we'll be here all day.
So unless you want to spend hundreds of hours trying to maintain a
growing bundle of exceeption handling, I really urge you to start from
one that woks well, such as the actively maintained cpanspec, and
expand it rather than starting from scratch.
-- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
