Re: glib1.1.5 bugs (was : Re: what's going on with gtk+ ????)
On Mon, 14 Dec 1998, Sven LUTHER wrote:
> On Tue, Dec 08, 1998 at 10:36:22AM -0800, Ben Gertzfield wrote:
> > >>>>> "Sven" == Sven LUTHER <luther@maxime.u-strasbg.fr> writes:
> >
> > Sven> i have compiled and uploaded the 1.1.5 versions of glib and
> > Sven> gtk ...
> >
> >
> > Sven> i noticed two things :
> >
> > Sven> * the glib.orig.tar.gz contains a directory named
> > Sven> glib-1.1.5, which is incorrect. should be renamed to
> > Sven> glib1.1.5-1.1.5 after the package name.
> >
> > No. Geez louise; I can't go changing the upstream tarball. I made the
> > source package be named glib1.1.5 instead of glib because we have to
> > support multiple versions. It breaks nothing to have the source name
> > be glib1.1.5. dpkg can handle it.
>
> last i checked, a package directory should be named package-version, and not
> something else. So if you change the package name, you have to change also the
> directory contained in the tarball. This don't change the upstream tarball so
> much and is the way to do things, at least according to the various packaging
> manuals available on the debian web site.
You've missed something. For some time now, dpkg and friends have been
able to handle a .orig.tar.gz that unpacks into any single directory.
> And yes it breaks something, if not, i would not even have noticed it, try to
> build your package with dbuild, it will complain about not finding
> glib1.1.5-1.1.5 after having untarred the tarball. I also think it is false,
> since gtk is handled correctly, and surely you can not say that for glib you
> cannot change the upstream tarballl, but that for gtk you can.
>
> also breaking the dbuild means that we get no automaticcaly builded package for
> non i386 architectures, ...
If dbuild is confused, fix dbuild. This is not a bug in the source
package.
> ha yes, but it don't seem to use glib-config, and since glib1.1.5 and gtk1.1.5
> don't install in the same place, it breaks the gtkglarea ... Like i wrote it.
>
> and i think itr is debian policy to put includes in /usr/include, and not in
> another place ...
And since the program doesn't use the DOCUMENTED interface to gtk, it is
buggy and should be fixed. There are reasons that the files are where
they are.
Reply to: