Re: Moving to a more distro/host agnostic setup for the canonical spec files.
- From: Yanko Kaneti <yaneti declera com>
- To: Daniel Ruoso <daniel ruoso com>
- Cc: gnome-packaging-list gnome org
- Subject: Re: Moving to a more distro/host agnostic setup for the canonical spec files.
- Date: 10 Jan 2003 14:14:33 +0200
On Fri, 2003-01-10 at 12:28, Daniel Ruoso wrote:
> I think that being rpm-oriented may not be a good policy.
If having a spec file means rpm-oriented then we've been rpm-oriented
for quite some time now. My post was defintely not about changin that
but rather making the current spec setup more general.
> One reason is that the rpm specification does not include all the
> features that other packaging systems do. i.e. debian.
I am not aware of any fundemental problems with rpm that make it less
suitable than other solutions. After all LSB is rpm based.
> The question is. Why not using simple tar.gz in the gnome distribution
> and each distro has one package manager (since the debian package
> manager will not be the same guy that build the rpm package)
We already have that, sort of. My idea is that we could do a tad better
and make the lives of the people that build things themselves a bit
easier. In addition to streamlining the process and avoiding duplication
whenever possible. Nowdays everyone and his brother maintain spec
repositories with each having its own set of silly gimmicks.
As a convenient place for package metadata I dont think that anything
current beats a spec file included with the one and only authorative
tarball.
(well... apart from a src.rpm but it says "rpm" in the name...people
start to get religious....)
> Em Sex, 2003-01-10 ās 07:15, Yanko Kaneti escreveu:
> > Hi
> >
> > Here is a packaging/spec idea I'll throw at the wind to seek some
> > general reaction and possibly action.
> >
> > Lets remove all the host/distro specifics that can found currently in
> > the spec.in files and move to using strictly defined subset of rpm
> > macros and techniques. Whenever the available rpm functionality lacks or
> > some extension is needed write new macros and include them in the
> > allowed subset. Maintain these extensions per platform. Distribute them
> > in the form of a package , say grpmbuild (or somesuch)
> >
> > Along the way:
> > - remove the requires and deps and rely on the hosts autodep, the
> > configure and pkg-config checks.
> > - remove direct calls to rm, make ./configure, ldconfig etc. and use
> > the available rpm macros
> > - remove the various gconf schemas install interpretations and similar
> > scrollkeeper-update hacks in favor of appropriate macros.
> > - generally remove all the hacks and workarounds e.g. all the libtool,
> > alpha, RPM_BUILD_ROOT != / trickery
> >
> >
> > All this gives? Imho more maintainability and portability. It would
> > allow the person/vendor wishing to adapt the build system to his own
> > setup by just adjusting the necessary rpmmacros. It would also result in
> > less maintenace effort for the spec (you wouldnt have to copy one hack
> > all over the place). It would make the "tarbuilding" of a rpm from the
> > vanilla source a more predictable process.
> >
> >
> > So, do you think this would work?
> >
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]