Hi,

Try the following:
"qmake-qt4 -project" or "qmake -project" if the qmake-qt4 command is not
available.
Then run "qmake", the Makefile should then be ready for your system.

Typically i need to create a "configure" file if everybody agree that
what i did make sense (i do not want to make extra developments if what
i do may be trashed in a near future).

BTW, you are right some features are still missing:
- not possible to remove a repository,
- not possible to mirror a repo.
But these two features are simple to implement. My only concern is that
currently i store repositories information into a file, not in the
database, i do not think this is the way to go; i want to figure this
point out before to implement any new feature.

Other note, the Qt GUI is independent to the commands used in the
backend (the opd2 command) so you can manage the repositories via the
CLI (interactive and non-interactive mode). Note that even the CLI is
not perfect since i want to know first what component will be interfaced
with ODA.

Regarding your remark about PackagePath, i do not understand what you
mean: there is a perl module specific to OPD/ORM and the only commands
that may be in PackagePath are the commands to query the repositories.
But it seems to me that these commands should be provided by Packman and
not by PackagePath. Do i miss something?

To conclude i think the question we have to answer, before to continue
any further developments on OPD/ORM, is to know exactly what interfaces
we want with the database (Selector vs. OPD/PRM, i.e., questions i asked
before but i did not have any clear answer).

Regards,


On Mon, 2007-11-05 at 19:34 +0100, Erich Focht wrote:
> Hi,
> 
> I tried to build it and found two issues in the Makefile:
> - it is using /usr/lib for linking the libraries. This should be /usr/lib64
>   on 64 bit systems, otherwise you enforce the usage of the 32 bits libqt4,
>   which people might not want to install.
> - QMAKE is hardwired as /usr/bin/qmake-qt4 . I suppose this is debian 
> specific,
>   under Suse there is no qmake-qt4, it is simply called qmake. Maybe you could
>   first try qmake-qt4 and switch over to qmake if it fails?
> 
> >From the logic (of what I've seen), I'm missing a way to remove repositories.
> Also I currently see no way of handling a distro that is different from what
> is installed on the master node. You'd need to add a selector for that at the
> top, maybe similar to what the "build image" panel is doing.
> 
> Otherwise (untested) sounds great. I'd like to integrate this with the new
> PackagePath functionality. Thanks for checking it in.
> 
> Regards,
> Erich
> 
> 
> 
> 
> On Saturday 03 November 2007 02:36, Geoffroy Vallee wrote:
> > Hi all,
> > 
> > OPD (OSCAR Package Downloader) has been modified to support
> > modifications introduced by OPKGC. Since OSCAR packages are not shipped
> > via binary packages, the notion of OSCAR package repository did change:
> > we now only deal with binary package repositories (current Debian or yum
> > repositories).
> > OPD therefore does not download anymore any packages. OPD allows:
> > - to add new OSCAR repositories (needed for third-party OSCAR packages,
> > - query local/online repositories to get information about available
> >   OSCAR repositories.
> > Because of that OPD becomes a tool for the management of OSCAR
> > repositories instead of a tool to download OSCAR repositories.
> > Furthermore, since everything is shipped via repositories, including
> > core OSCAR packages, it is possible to extend OPD to the management of
> > third-party repositories but also the default OSCAR repositories that
> > are needed for the installation of core OSCAR packages.
> > 
> > Therefore the new OPD includes several capabilites:
> > - keep a list of OSCAR repositories,
> > - for some or all repositories, get the list of available OSCAR
> > packages,
> > - keep a list of default OSCAR repositories.
> > 
> > For that the new OPD is actually composed of two differents components:
> >   - a command line tool which allows users to use OPD in interactive and
> > non-interactive mode (based on the old OPD, before the introduction of
> > OPKGC). This part of OPD is implemented in Perl and the non-interactive
> > mode has been designed to be used by other tools (such as the graphical
> > interface). The script is '$(OSCAR_HOME)/scripts/opd2'. For details
> > about the usage of the opd2 tools are available when executing "opd2
> > --help".
> >   - a graphical tool which allows users to add repositories and query
> > them about the available OSCAR packages. Note that since OPD2 does not
> > download any OPKG anymore (usage of online repositories), the GUI is
> > named OSCAR Repository Manager (ORM). This tool is based on OPD in
> > command line (non-interactive mode) and is implemented in C++/Qt4. The
> > reason why the graphical interface was not implemented in perlQt are:
> >     * the latest version of perlQt only support Qt < 3.3 which is a very
> > old version of Qt, note compliant anymore with Qt tools shipped in the
> > major Linux distributions.
> >     * C++/Qt4 is one of the latest technology for the creation of new
> > GUIs.
> >     * because the script 'opd2' can be used in non-interactive mode, it
> > is not necessary to use perl modules; therefore the usage of C++ does
> > imply any conflict with the existing OSCAR code.
> >   At the same time, this is only a first implementation i quickly
> > implemented (i did already know pretty weel C++/Qt); if need it is still
> > possible to reuse .ui files and create the GUI in perlQt (or any other
> > language that can be used with Qt). The code is available in
> > $(OSCAR_HOME)/src/ORM; it can be compiled executing 'make'.
> > 
> > Note that the new version of OPD can clearly populate the OSCAR database
> > about available OSCAR packages. However, the OSCAR development team did
> > not agree yet on this point and therefore the interface with ODA is not
> > implemented.
> > 
> > Todo:
> > - clean up the code,
> > - improve code comments,
> > - use doxygen for the ORM code,
> > - change the name of perl scripts, OPD2 does not make much sense since
> > we do not download packages any more, we only deal with repository.
> > - implement an interface with ODA?
> > 
> > Note that this text is also on the Wiki.
> > 
> > Regards,
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Oscar-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/oscar-devel


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Oscar-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oscar-devel

Reply via email to