Re: Moving to a more distro/host agnostic setup for the canonical spec files.

Em Sex, 2003-01-10 às 10:14, Yanko Kaneti escreveu:
> 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.

And that is what I am talking about. I think gnome should not stick to
any distro or packaging format. (I think I agreed with you, in part)
 
> > 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.

Well, i think the flamewar deb x rpm is not the case here. After all LSB
is not consensual.

> > 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. 

I think the distributions are responsible for packaging the software in
their format. This means that gnome packages won't define much as a
gnome package, since gnome is not a distro.

But the gnome software are splitted into packages (and that is not rpm
or deb). A gnome package is a piece of software. So, what standards we
should apply to gnome packages? Here is an example list (a proposal).
 - The use of tar.gz for source distribution
 - gnome packages are in source format. Binary formats are
responsability of linux distros.
 - The gnome packages should follow FHS (Filesystem Hierarchy Standards)
 - Dependencies should be documented in some generic format (to be used
by distro packagers)
 - Well, this is just a example list

And this policies should not include definitions for rpmmacros, since
this is distro specific.

> 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?
> > > 
> 
> 
>