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

Re: installer for non-free packages in contrib



Andreas Metzler <ametzler@downhill.at.eu.org> a tapoté :

> Mathieu Roy <yeupou@gnu.org> wrote:
> > Colin Watson <cjwatson@debian.org> a tapoté :
> >> On Tue, Sep 09, 2003 at 09:17:13AM +0200, Mathieu Roy wrote:
> >> > Colin Watson <cjwatson@debian.org> a tapot? :
> >> > > I asked you a question which could be answered quite simply by producing
> >> > > one of those ways. Go on. It's my honest belief that it can't be done
> >> > > correctly; I'm open to hearing ways in which I'm wrong.
> >> > 
> >> > Instead of having a package the binary and install it, we can surely
> >> > have the package that set up a directory in /usr/src with everything
> >> > needed to be build the debian package + a script in /usr/bin that
> >> > would create the package and install effectively (named after the
> >> > installer package name, for instance).
> >> > 
> >> > There's no reason when you install an "installer" to have a software
> >> > installed, apart from the installer itself. You should have a tool
> >> > that permits you to install the software and that's what I'm proposing.
> >> > 
> >> > If you remove the installer, all these files would be removed, whatever
> >> > the fact you may have build and installed the non-free software or
> >> > not.
> >> > 
> >> > I think it's a pretty easy solution to have something clean.
> >> 
> >> I think that's a step backwards. In particular, it's now impossible to
> >> have an installer package which Provides: a virtual package in a
> >> sensible way;
> 
> > Which "virtual package"? The package that will be built will be a
> > completely normal package.
> [...]
> 
> Let us say we are talking about foo-runtime, a interpreter/virtual
> machine that many packages in contrib depend on. If the installer
> package worked as you proposed it wouldn't fulfil its puprose, the
> foo-runtime-installer does _not_ provide foo-runtime

As you telling me that currently foo-runtime-installer, a package in
contrib considered as free depending on non-free software, have in his
Provides: foo-runtime???

Gosh! It's even worse that one could ever think. So we have package in
contrib that plainly assume the fact that they contains (_provides_)
non-free software, and they are still in contrib?

> , so "apt-get install foo-blahfasel" will simply fail, because there
> is no package providing foo-runtime available.

Yeah, there no such package until you run 

        /usr/bin/foo-runtime-installer

shipped with foo-runtime-installer, which one will build the package
and install, from /usr/src/foo-runtime.

Until you do not explicitely install this package foo-runtime that you
built at home (because there's no other legal way to have package that
can truly be providing foo-runtime), get this package foo-runtime in
the database as it is, you cannot do "apt-get install foo-blahfasel".

> 
> This doesn't just happen on initial installs but also on upgrades (WTF
> is foo-runtime >= 1.4?)

foo-runtime is here only when you build it.

Yes, there are problem with distributing non-free software. And a free
software completely depending on a non-free software is basically a
partially non-free software.

But right now, you already have the same problem: having
foo-runtime-installer does not at all proves that you have foo-runtime
truly installer (yes, look at the Flash installer, you can have the
package and not having Flash) -- so WTF is foo-runtime >= 1.4?


-- 
Mathieu Roy
 
  Homepage:
    http://yeupou.coleumes.org
  Not a native english speaker: 
    http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english



Reply to: