Re: Where to put spec files...

[Roy-Magne Mo <rmo sunnmore net>]

On Mon, 2002-01-21 at 10:22, Chipzz wrote:
> On 20 Jan 2002, Roy-Magne Mo wrote:

> > The redhat spec-file should be left in the tar-file so one can build a
> > rpm directly from the tar file. Possibly softlinked from the package
> > directory. As the redhat specfile also works on mandrake, this will be
> > used by most people.
> 
> Works. But that's about it. Replacing old packages with RH-style packages
> won't work (not in the simple case that is)
> 
> Suppose you have gtkhtml:
> Mandrake has gtkhtml, libgtkhtmlx, and libgtkhtml-devel (I may be off a bit,
>  but you get the idea)
> RH-style has gtkhtml and gtkhtml-devel. Thus upgrading to these packages
> will cuase a conflict between gtkhtml and libgtkhtmlx, and between
> gtkhtml-devel and libgtkhtml-devel. So you'ld have to uninstall those first,
> screwing up your database.


Should not really be a big problem with a sane upgrading system, like
apt.

But this might be the way to do some gnome packages too, as gal - which
seems to be upgraded whenever Evolution is released. This might call for
such intermediate packages.

 
> To summarize my point:
> 1) The RH spec-files should stay in the root dir of the package in CVS, and
>    updated to working versions.

agreed

> 2)
>  a) The other spec-files should be distributed in a directory of the pack-
>     age in CVS, better still, including spec.in's.

agreed

>  b) The other spec-files should be distributed seperately, maybe in a CVS
>     module or tarball? Maybe we could also include spec.in files?
> 3) The debian directory in CVS should stay and be updated.

agreed

> This has the following advantages:
> 1) RH and Debian can easily build packages, both from tarballs and out of CVS.
> 2) We can easily make SRPM's for the other distro's.

Having spec.in files in the package that's upgraded at every release
would be the best, but that's probably utopia.

So maintaining seperated spec's/spec.ins in an seperated cvs module
might be the right thing to do after all, especially when you wan't to
fix packaging bugs.