All of my comments are based on an RPM background - I'm sure that DEB's
can be integrated into these thoughts as well - even Solaris PKG's and
BSD ports.
On 13 Jul 2001 12:23:44 -0400, Brian S. Julin wrote:
>
> On 13 Jul 2001, Thayne Harbaugh wrote:
> > I still feel very strongly about having a tight integration between the
> > individual libraries and the files that package them - I thingk it will
> > be encorage and improve maintainability. The spec file doesn't have to
> > be in a sub-directory but could go in ggi-core/libgii directly (similar
> > for all libs in CVS).
>
> "the" spec file? Is there to be only one per lib? I have seen before
> packages where there is a specfile alongside every Makefile.
>
> > If my suggestion is rejected I'll be sad =(
>
> These are my main concerns; if we can work out something that keeps
> us both somewhat happy, let us try:
>
> 1) Make sure that we do not make it harder for a distro
> maintainer who does not have/want CVS access to write new
> packaging scripts by putting things in their way.
You can still use a different spec file to build an RPM even if a
refernece spec file is included with the source.
> 2) If another RedHat based distribution wanted it's own customized
> packages, there should be a way for them to be stored in CVS.
> E.g. we'd have a distro/redhat and a distro/suse if suse did not
> like the way vanilla redhat packaged something.
Usually RedHat, Caldera, SuSE, Ximian and others all maintain their own
private spec files outside of source packages. What is accomplished,
however, in including a spec file with source is that there is a
reference implimentation for everyone. There is also an easy way for
people to build RPMS if the last version of a distribution has an old
library and the usser wants to update to a newer version that the
distribution provider hasn't packaged yet. There is also the
possibility that a distribution provider decides not to package GGI, yet
someone with an RPM system wants to build and install GGI using RPM's.
> 3) If some distro wants to pre-patch our code in some way that
> we do not want in our mainstream code, these patches should not
> clutter up the mainline tree, but we should still be able to keep
> them in CVS if we want.
Those types of patches are usually maintained by distribution providers
and not in software projects. I might be wrong, but I can't imagine a
distribution provider wanting us to maintain their patches for them in
our tree if we aren't going to incorporate them as patches in to the
source - especially if that distribution provider doesn't have CVS
access. I'm sure the distribution provider would find the process
too slow for their patches or we would find that our releases would
need to be shipped before we received patches back from the
distributions - which would always mean that our releases with the
packaging files would be out of date.
> 4) distros which want to take one thing from LibGII and one thing
> from LibGGI and one thing from LibGGIMISC and put them into the
> same distro-package can still have their distro scripts store in
> CVS alongside everyone else's. I think having all the distros
> side by side is good also because it will foster a competitive
> spirit between them for packaging.
>
> Some of the above concerns are not likely (but eventually could
> end up being, if rpm improves to include features in more
> advanced packaging systems) an issue for RedHat, but I think if we
> have RPMS files in the CVS lib trees and everyone else's in a
> separate CVS tree, we will look like we are playing favorites.
I don't want to play favorites either, yet I don't want to sacrifice
including useful tools because no one has provided equivalents for
other systems. Keep in mind that the spec file I have submitted would
be GGI's recommended reference spec file and individual distributions
would have the liberty to change and do their own - as well as submit
patches to ours.
> I have no problem with having Makefile targets which will either
> copy the distro files in and build, or generate a source tarball
> with the distro files copied in, for any given distro e.g. "make
> suse-dist". That would be a "maintainer level" makefile rule,
> and it is OK for it to know that the RPMS files are all in
> ../../distro/redhat.
>
> --
> Brian
Suddenly I understand why this is so wrong to me - having files outside
of the library tree. Say you want to do a "make dist" to package up
libgii for distribution. This "dist" target would need a dependency
that goes to ../../distro/redhat and copies files from there and places
them into the source distribution. Right now everything is
self-contained in libgii. With this suggestion everything is not
self-contained. The problem now is that you send out the source tar for
people to consume. Some people decide that they want to play arround
with this source at a low level - possibly to send in a patch.. They
now can't do everything and test everything because their source is
incomplete - it doesn't include ../../distro/redhat.
Some may claim that this isn't a problem - if someone wants to play at
such a low level then they should check everything out of CVS. I know
that many times I have wanted to play with source without going through
the hassle of checking things out of some CVS tree - mostly because it's
a temporary need to play with the source. This is very frustrating to
do when the source is incomplete and principle functions, such as "make
dist", don't work.
I consider it bad form to distribute incomplete source that can't stand
alone and have its expected functions complete - if not all of its
functions complete.
The only other way is to not distribute any packagine files.
--
Thayne Harbaugh
