Re: Where to put spec files...

["R.I.P. Deaddog" <maddog linuxhall org>]

On Mon, 21 Jan 2002, Chris Chabot wrote:

> >Mandrake is using the library policy used in debian packages:
> >For example, gtkhtml/libgtkhtml19/libgtkhtml19-devel.
> >
> Ok.. that does suck ;-) However, if we get a knowledgable mandrake 
> packager, wouldnt it be posible to use 'Obsoletes' and 'Conflicts' in 
> the RPM to deal with this semi-grasefully? The nice thing about 
> attempting to solve some problems this way would be that it doesnt 
> conflict with other platforms, since those package names are not in use 
> on those platforms.. so basicly there ignored.

I'd have no comment for the Mandrake's choice, but personally I think
this library policy of Debian is a great idea, instead of being suck.
For example, you can install multiple of glib 1.3.x (not devel package,
only the lib). While newer app are compiled with newer glib, you are not
forced to remove or break older app which are compiled with older glib.

Theoretically, this will solve all library incompatibility problem, both
now and in the future. But it introduce another problem: cryptic library
names. This is a direct consequence of maintaining compatibility. For
now, you can go to my site to have a look:

http://www.cle.org.hk/~baddog/files/Mandrake/GNOME2/latest/sources/

Perhaps you can get some idea what my 'cryptic' means, when you go to
have a look in the spec files in my SRPMs. I haven't announced it since
I am busy with my personal stuff and not following Gnome development
temporarily.


> >>I'd say, lets make our own naming convention (ie 
> >>"base_package_name-major.minor.sub.RPKFORMAT", and use the redhat / 
> >>gnome style naming for our libraries (gconf2, gnome-vfs2, etc) This way 
> >>
> >Do I get it wrong... redhat style and gnome style are a little bit
> >different now? (e.g gconf2/gnome-vfs2 etc for Redhat, and gconf/gnome-vfs
> >for Gnome)
> >
> Well, yes and no... thats actualy one of my many hangups with the 
> current packaging situation.
> 
> The tarbals are names in the base_name-version convention style (ie 
> gconf-1.1.6), however the location into which they install, and the 
> naming of their libraries are following the -2.0 style.
> 
> the problem with following the base_name-version style is that it messes 
> up the whole concept of being able to have both gnome 1.4 and 2.0 
> libraries installed on your system.

Fully understandable, it bites me in the same way. rpm -Uvh means
upgrading 2.0 library in addition to removing 1.4 library.

> This will not bite you if you do a simple ./configure && make && make 
> install from the tarballs, however for packaging, which _removes_ the 
> files of the package your upgrading, the problems are very present ;-)
> 
> (ps, this is why i, where my knowledge was sufficient, put in Conflicts 
> < old_gnome_version in the RPMS im building, you _need_ a newer gnome 
> for the dual install to work).

You may ask Havoc for this, since he started all the parallel install
planning. AFAICT, here are a few conflicts:

libglade2:		BuildConflicts libglade < 0.17
libglade2-devel:	Conflicts libglade-devel < 0.17
ORBit2:			BuildConflicts ORBit < 0.5.10
ORBit2-devel:		Conflicts ORBit-devel < 0.5.10

Certainly there are more, but I have no time to dig them out.

> >>we are compatible with the highest percentage of people, and have a 
> >>clear standard to submit to SuSe & mandrakem which do not have to break 
> >>their old releases and base system designs.
> >>
> >Agreed again, if any clean solution is proposed.
> 
> Well, lets keep pluggin away at it ;-)

For now, I failed to see any solution now: either break all distro other
than Redhat, or let various distro choose name themselves. Hope that can
change later.

Abel