QT2 ready for ITP?

["Ralf Habacker" <Ralf dot Habacker at freenet dot de>]

Ralf Habacker wrote 
> > > One thing that should be discussed will be how to divide the
> > packages,
> > > which was stated (a little) in cygwin-xfree. Currently I'm
> > preparing
> > > a (from my point of view usefull) schema and will send it to the
> > list the next
> > days, so
> > > that packaging could start.
> > 
> > Packaging should be adapted by the users need, so the first
> > question is what
> > does the users expect. I assume the following:
> > 
> > 1. Users want to download and start qt applications. They need (a)
> > the package
> > containing the qt dll and the (b) requested application package.
> > 
> > 2. Users like to port their unix qt application to cygwin. They
> > need at first
> > (c) import libs and the headers, (d) perhaps the docs. For testing
> > they need (e)
> > the package containing the qt dll probably with debugging
> > informations.
> > 
> > 3. User want to learn qt programming. They need (c) the import
> > libs, headers,
> > (f) the examples, tutorials, (d) the docs and (e) the package
> > containing the qt
> > dll (with debug informations).
> > 
> > (a) qt dll without debug informations
> > (b) qt applications
> > (c) import libs and header
> > (d) qt docs
> > (e) qt dll with debugging informations
> > (f) examples and tutorials
> > 
> > (a) should be released anyway
> > (b) also
> > for (c), (d), (e) and (f) there are several posibilities.
> > 
> Ralf,
> 
> Here is how I would like to do it:
> 
> 
> package #1 - qt-2.3.1-n.tar.bz2:
> Contains (b) with basic docs (REDAME's, etc.).
> 
> (b)'s applications will be transformed from 
> "foo.exe" to "foo_2.3.exe" during "make install".
> 
> A post-install script will make symlinks 
> to the standard names of the applications.
> 
> 
> package #2 - libqt-2.3.1-n.tar.bz2:
> Contains (a) only
> 
> 
> package #3 - libqt-devel-2.3.1-n.tar.bz2:
> Contains (c) + (d) w/post-install script to 
> symlink to the default headers and libraries.
> 
> Also the post-install script will generate
> suitable /etc/profile.d scripts to set the
> environmentals.
> 
> 
> package #4 - libqt-extras-2.3.1-n.tar.bz2:
> Contains (f) only
> 
> 
> package #5 - qt-2.3.1-src-n.tar.bz2
> Contains full qt-2.3.1 sources for rebuilding
> plus a method #2 script to automate this task.
> 
> 
> As for (e), I see no need to release a debug version, as people will
> be able to recompile the package with debugging if they want it.
> 
> 
> If we want to have qt2 and qt3 coexisting, then we need to provide a
> suitable directory structure for the Cygwin mirrors.  To prevent
> clobbering, and improper parsing by upset, we will put the packages
> in the following directory structure:
> 
> qt/qt2.3/ - #1 & #5
> qt/qt2.3/libqt2.3/ - #2
> qt/qt2.3/libqt2.3-devel/ - #3
> qt/qt2.3/libqt2.3-extras/ - #4
> 
> This is how I've been packaging the berkeley db, and it works quite
> well.  To explain my rationale, considier what would happen if the qt
> people released qt-3.1.X, which was slightly incompatible with some
> application source code built with qt-3.0.X.  With my method, the
> last installed qt and/or libqt-devel package becomes the default, but
> DOES NOT clobber the other qt and/or libqt-devel packages.  This is
> extremely handy when you are trying to target a particular version of
> the qt api.  I'm still working on my scripts, but eventually I'll
> have menu-based selection of which version of the API should be
> default (maybe it will be a readline based c application).
> 
> Cheers,
> Nicholas
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - Feel better, live better
> http://health.yahoo.com
> _______________________________________________
> kde-cygwin mailing list
> kde-cygwin@mail.kde.org
> http://mail.kde.org/mailman/listinfo/kde-cygwin
>