random thoughts on software installation
by Colin Walters
Recently as part of the online desktop project we've been doing some
work on installing desktop applications, a blog entry is here:
http://clarkbw.net/blog/2007/05/04/bullish-on-finding-new-applications/
However, what I was thinking about on the drive in this morning though
is how we could make the experience kick ass for the other kinds of
software out there, like developer libraries and tools (foo-devel,
mercurial) and server software (postfix).
For the first part - developer software, my ideal tool would look
something like this. Just a search box, and a list of result hits.
Like a web search engine basically.
/-----
| Search: [ hg ]
|
| Package: mercurial _Install_
| - /usr/bin/hg
|
\-----
Searches executable names
/-----
| Search: [ db.h ]
|
| Package: libdb2-devel _Install_
| - /usr/include/db2/db.h
|
| Package: libdb3-devel _Install_
| - /usr/include/db3/db.h
\-----
Searches files.
/-----
| Search: [ ssh python ]
|
| Package: python-paramiko _Install_
| "Paramiko is an implementation of ssh for Python..."
|
| Package: openssh _Install_
| - /usr/bin/ssh
\-----
Searches descriptions and names too.
No support for conflicts[1], removing packages[2], installing multiple
packages at a time[3] (if the user clicks multiple, just queue them up),
updating to new package versions[4], whatever. Let me search for that
developer thing I need and one click blat it to the disk from the web.
Menu entry would be 'Install Programming Tools'. Would require a local
cache of the contents of all packages - also being able to search the
individual symbols in things like shared libraries, Python modules, etc.
Probably large, but I bet gzip would do quite well on it for a CD, and
hard disks are big so store uncompressed to make it fast. Use rsync to
periodically keep it up to date. Or perhaps we could dump the local
cache idea and have it be a fedoraproject.org web service.
Now there's another class of software - server software like apache,
mediawiki, postfix, etc. These kinds of packages could legitimately
conflict with others. But the difference is a lot more fundamental -
for this kind of software, downloading the package is only the *very
first* step in actually getting it working. You have to configure
these, and there's no way around that. We could talk a lot about
what installing server software could be like, but an idea of where we
could go would be towards something like "RHX for Fedora":
https://rhx.redhat.com
Being able to click on Postfix and click on reviews, comparisons to
other things like Sendmail would be cool. I know we have some people
that are passionate about particluar server software that would likely
add reviews. Could be hosted on the fedoraproject.org wiki.
A super small thing that would be *easy* to implement for server
software would be to include a "Next-Step-URL" or something in the RPM
spec file that opens in a browser after you install the software. Let's
be realistic - admins rely on the web for setting these things up.
Unless you're an admin god, but in the case you are you can help add to
the wiki page =)
We could define this to always point to a fedoraproject.org wiki page,
which could then link to "official" setup instructions like:
http://www.mediawiki.org/wiki/Installation
and also have Fedora-specific tweaks and instructions, like a link to a
description of the Fedora Apache SELinux policy, etc. If there was no
content on the fedora page it could just be an auto-redirect to the
upstream site until some content is added.
Anyways, just some random thoughts.
[1] None of this software should conflict with anything else.
[2] Should be extremely rare to remove any of this stuff...in the odd
event you are really scraping for disk space, an "out of disk space"
tool could detect which things are unused, but it's more likely
anyways that what's actually eating your disk space is all those
Battlestar Galactica or whatever episodes you've been
bittorrenting. Bad user!
[3] Don't need transactions, etc...as soon as the user clicks start
downloading and installing. Since there are no conflicts there
shouldn't be an issue.
[4] The pirut update applet is great for this
17 years, 1 month
Proposal ocaml guidelines
by Hans de Goede
Hi all,
I got looking into this because of these review requests:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235804
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235805
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235815
And I've come to the conclusion that we need some kinda ocaml packaging guidelines.
Interesting with regards to this are:
http://docs.pld-linux.org/ocaml.html
http://pkg-ocaml-maint.alioth.debian.org/ocaml_packaging_policy.txt
Which are PLD resp debian ocaml guidelines. And they seem to agree on most things.
Notice that I've exactly 0 experience in packaging or writing caml software,
this is all based on common sense and my observations with the 3 packages above.
OCaml Guidelines
================
Naming
------
OCaml modules / libs should be named ocaml-foo. (This does not apply to
applications written in caml). Rationale: this is how they are named in other
distros (Debian, PLD) and this is consistent with perl / php / python.
-devel sub-packages
-------------------
OCaml software can either be byte compiled, in which case it will need the
ocaml runtime and besides the runtime only the files installed by libs /
modules under /usr/lib/ocaml/stublibs (the ocaml byte code from libs gets
staticly linked into the bytecode-"executable"_.
Or they can be compiled to native code in which case all caml specific libs /
bindings get staticly linked into the executable (wrapped libraries themself
will still be dynamicly linked, but the wrapper code is linked staticly into
the executable, this can not be changed).
Thus for ocaml modules / lib(wrapper)s, in the case of byte compiled ocaml
programs only the files under /usr/lib/ocaml/stublibs from the module/lib are
needed, and to run a compiled program nothing from the module/lib is needed.
So only the files under /usr/lib/ocaml/stublibs should be in the mainpackage,
and if there are no such files (in case of a pure caml module / lib) then the
mainpackage should have an empty %files. All other files should go in a -devel
package as they are only needed to compile and no to run ocaml programs.
Unnecessary files
-----------------
This is taken from:
http://docs.pld-linux.org/ocaml.html
Following files should NOT be distributed:
- *.cmo object files. There is however one exception -- if file is needed for
link (like gtkInit.cmo in lablgtk or std_exit.cmo in OCaml itself), then it
should be of course included.
- *.o for corresponding *.cmx. They are included in *.a anyway. Exception -- as
above.
- *.ml sources.
- *.mli interface sources. However, if package lacks any documentation (which
is unfortunately often the case), you can include *.mli, but it should be
gziped and placed in package as %doc.
Regards,
Hans
17 years, 1 month
Conflict in /usr/lib/kde3/plugins/styles/keramik.so:
by Neal Becker
I ran this on current fc7test with all updates, on x86_64:
kdiff3 idma-cdma idma-cdma.nbecker4
Conflict in /usr/lib/kde3/plugins/styles/keramik.so:
Plugin uses incompatible Qt library!
expected build key "x86_64 Linux g++-4.* full-config", got "i686 Linux g++-4.* full-config".
What does this mean?
BTW, I'm the kdiff3 maintainer, so maybe I need to do something?
17 years, 1 month
Re: rawhide report: changes -- conflicts between attempted installs of kdebase-3.5.6-10.fc7 and kde-settings-kdm-3.5-23.fc7
by Miles Lane
On 5/17/07, Miles Lane <miles.lane(a)gmail.com> wrote:
> On 5/17/07, Brendan Conoboy <blc(a)redhat.com> wrote:
> > Bill Nottingham wrote:
> > > The fix has been pushed to the mirror master and should propagate out soon.
> > > Why the entire tree synced except for the i386 primary.xml.gz... I'm not sure.
> >
> > Also repomd.xml needs to be regenerated with primary.xml.gz's updated
> > sha1 sum.
>
> I have successfully gotten the updates.
Transaction Check Error:
file /usr/share/config/kdm conflicts between attempted installs of
kdebase-3.5.6-10.fc7 and kde-settings-kdm-3.5-23.fc7
file /usr/share/config/kdm/Xaccess conflicts between attempted
installs of kdebase-3.5.6-10.fc7 and kde-settings-kdm-3.5-23.fc7
file /usr/share/config/kdm/Xsession conflicts between attempted
installs of kdebase-3.5.6-10.fc7 and kde-settings-kdm-3.5-23.fc7
file /usr/share/config/kdm/Xsetup conflicts between attempted
installs of kdebase-3.5.6-10.fc7 and kde-settings-kdm-3.5-23.fc7
file /usr/share/config/kdm/Xwilling conflicts between attempted
installs of kdebase-3.5.6-10.fc7 and kde-settings-kdm-3.5-23.fc7
file /usr/share/config/kdm/backgroundrc conflicts between attempted
installs of kdebase-3.5.6-10.fc7 and kde-settings-kdm-3.5-23.fc7
file /usr/share/config/kdm/kdmrc conflicts between attempted
installs of kdebase-3.5.6-10.fc7 and kde-settings-kdm-3.5-23.fc7
17 years, 1 month
Different python versions in a Fedora system
by Kushal Das
Hi,
Is there any way to keep different Python versions in a Fedora system ?
There will some installation (around 292) state wise in kiosks. But the only
reason the team is refusing Fedora is its lack of support of keeping &
running different versions of Python . So, is there any work around ?
Kushal
--
Fedora Ambassador, India
http://kushaldas.in
17 years, 1 month
Re: rpms/drgeo/EL-4 drgeo.spec,1.3,1.4
by Ralf Corsepius
On Thu, 2007-05-17 at 05:55 -0400, Eric Tanguy wrote:
> Author: tanguy
>
> Update of /cvs/extras/rpms/drgeo/EL-4
> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv2999
>
> Modified Files:
> drgeo.spec
> Log Message:
>
>
>
> Index: drgeo.spec
> ===================================================================
> RCS file: /cvs/extras/rpms/drgeo/EL-4/drgeo.spec,v
> retrieving revision 1.3
> retrieving revision 1.4
> diff -u -r1.3 -r1.4
> --- drgeo.spec 3 Nov 2005 18:19:11 -0000 1.3
> +++ drgeo.spec 17 May 2007 09:55:13 -0000 1.4
> @@ -1,7 +1,7 @@
> Summary: Interactive educational geometry software
> Name: drgeo
> Version: 1.1.0
> -Release: 4%{?dist}
> +Release: 5%{?dist}
> License: GPL
> Group: Applications/Engineering
> URL: http://www.ofset.org/drgeo
> @@ -10,7 +10,7 @@
> Patch0: drgeo-1.1.0-htmlview.patch
> BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
>
> -BuildRequires: flex, bison, gmp-devel >= 2.0.2, desktop-file-utils
> +BuildRequires: flex, bison, gmp-devel >= 2.0.2, desktop-file-utils, perl-XML-Parser
Please use perl(XML::Parser) instead of perl-XML-Parser
Ralf
17 years, 1 month
Re: rpms/kdelibs/devel kdelibs.spec
by Rex Dieter
Than Ngo (than) wrote:
> Author: than
> Update of /cvs/extras/rpms/kdelibs/devel
> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv29578
> Modified Files:
> kdelibs.spec
> Log Message:
...
> - disable kde_settings
wtf? I just went through the work enabling kde-settings, why are you
disabling it?
-- Rex
17 years, 1 month
Outage Notification - 2007-05-17 04:00 [UTC]
by Mike McGrath
There will be an outage starting at 2007-05-17 04:00 [UTC], which will last
approximately 1 hour. To convert UTC to your local time, use:
http://www.timeanddate.com/worldclock/converter.html
Affected Services:
Buildsystem
Unaffected Services:
Websites
CVS / Source Control
Database
DNS
Mail
Torrent
Reason for Outage:
Upgrading Koji to a new version and moving koji store to new hardware. This
outage should be approximately 1 hour, maybe longer if the sync is running
slower then expected. Will be coordinating in #fedora-admin The build system
should either reject connections or queue connections during this time.
Contact Information:
Please join #fedora-admin in irc.freenode.net or respond to this email to track
the status of this outage.
17 years, 1 month