On Fri, Sep 22, 2006 at 09:18:42AM +0200, Andreas Jellinghaus wrote:
how are projects and packages structured?
is it a fixed "one name for the project and then one for the package"
system, or are further subdirs possible?
I wonder about this: recent discussions with rpm experts have shown me
that merging several spec files into one only creates a horrible
You also get a horrible maintainence hell if you have lots of specfiles,
because you'll have to keep them in sync if you add patches and the
also they have compelling arguments, that one rpm for
all distributions was something they tried for years with lots of work,
and it never worked well.
right, that's why we have the build service. Automatically create rpms
for lots of distributions.
so I see as best solution to have codenames (e.g.
sles10, oss10.0, dapper, edgy, etch, sarge, ...) and for each
distribution *.spec.$codename or *.diff.gz.$codename. but this would
require work on the build system side, and I get the impression noone
the alternative from my side would be per distro packages.
e.g. instead of "openct" I could have packages "openct.fc" and
"openct.os" and "openct.sles" and "openct.sarge" and so
upload spec files for each. this wouldn't require changes in the code
base, and give me the flexibility I need, so I can simply build new
packages for my open source projects, with minimal changes to the last
spec file the distribution provides.
but that way the list of packages might grow very long. is it possible
to structure projects/packages a different way (i.e. path mechanism,
no flat one project, one package subdir structure)?
I'm just preparing a patch that makes the build service look for
<package-name>-<repository-name>.spec if a package contains multiple
specfiles. So you can have a different specfile for every repository.
I prefer a single specfile, though.
Michael Schroeder mls(a)suse.de
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org