[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]

RE: [XaraXtreme-dev] Installation options



> > From what I've seen so far, even if we supply deb and rpm packages
that
> > know the dependencies, there is no simple way for users to install
those
> > packages in a way that satisfies any dependencies. On Ubuntu for
> example,
> > I'd expect right-clicking or double clicking on a deb file to
present
> > an install option. What else am I likely to want to do with a deb
file?
> > But nothing useful is provided. Even Synaptic doesn't allow
> > installation of a deb file that you've already downloaded. And there
> > doesn't even seem to be a single command that will do the install
job.
> > dpkg will install a deb file, but will only complain about
dependencies
> > rather than do anything about them. And apt-get will auto-install
> > dependencies, but won't take a deb file!
> 
> Can't you just point synaptic at multiverse and say "Find XaraLX" and
> then go from there? (once it's in multiverse)
> 
> Or, if you want it even faster, just allow users to specify the
> Xara webserver as a repository server - that's just setting up
> a directory as far as I know. Then they'll get autoupdates, etc. etc.
> This is how WINE works, for instance.
> 
> That's how the package system is meant to work. Whilst it's possible
> at a command line level to install a package from a single .deb
> file, this is not in general the world's best way to do it as
> you won't get updates.

I didn't think such a move would go down well. I thought that the
package managers were only supposed to point to repositories of software
that had been built, tested and approved for that distribution by the
providers of the distribution. But if this would be accepted then this
is a good option.

But won't it get confusing once the main distribution repositories also
contain a Xara LX package? Perhaps it won't matter which one users
choose as long as we use the same package version numbering scheme and
same file locations, etc.

> 
> > On Fedora it's better because "yum localinstall" seems to do the
> > job, though it refuses to install rpm files that aren't signed,
without
> > first tweaking it's config.
> 
> Can't you self-sign them?

How do I do that? I thought I had to use gpg to generate keys and setup
a key server somehow.

> 
> > One option I'm considering is providing just a shell script that
users
> > download from us and run. It would check the system type, then would
use
> > wget to download either an rpm or deb file as required. Then it
would
> use
> > combinations of dpkg, apt-get, yum, rpm, etc. to install the package
> plus
> > dependencies.
> 
> Well that would work, but why wouldn't you make it (for instance) add
the
> repository. Note either way you'll have to get their root password at
some
> point in order to do apt-get (gksudo will do this in a pretty box).
Some
> people might be understandably hesitant about this.

Yes, the script would have to be run as root. Good point about users
being reluctant to do this, so this probably isn't a good option.

> 
> > Please let me know your thoughts and any attractive options that
I've
> > missed. And specifically:-
> >
> > - Are dpkg and apt-get likely to be present and consistent on all
debian
> > based distributions?
> 
> Yes.
> 
> > - What about yum on rpm based systems?
> 
> Pass. Not used redhat / rpm since before yum existed.
> 
> > - Could we rely on wget being present so we can smart-download the
> > appropriate package type for a system from a single script?
> 
> wget is not installed by default on some systems (minimal debian
install
> for instance didn't used to have it, don't know whether it does now).
> But the debian tools you can pass a URL to I think, and they will pull
> down the stuff themselves. Joachim will be far better placed to answer
> all this than me.

Ok, so it seems the best way forward is for us to just provide an rpm
and deb file on our web site for now. Along with (not as simple as we'd
like) instructions on how to install each one. Then once we're confident
about the packages we're building, we can look at providing them via a
repository as well.

Thanks

Neil