Re: Proposal: Fixing non-free content issues via installer packages
Eddy Petrişor wrote:
> I will. I suppose you are willing to work on such a project, I am
> willing, too, is there anybody else willing to get involved in
> implementing this?
I personally think we should discourage distributing non-free content.
>>> Maybe we should implement some abstract retriever which
>>> would take the files from the local file system, a CD or a
>>> site ... you name it. The user would choose where from to
>>> get the file
'quake2-data' seems to be doing just that.
>> Sounds good. I'd like such a framework to support displaying
>> a licence to the user and requiring it to be accepted, for
>> some things.
>
> Yes, that is an important point in some cases, we could also use it as
> warning displayer in early development stages ;-)
Nobody reads that stuff. Something like...
'This software is NOT free. You are NOT allowed to modify or distribute
it. It is not supported by the Debian project in any way.'
...would be much better, in my opinion. Or that plus the license.
>> I don't think this should be done via debconf. It's too much
>> work with too many failure cases to do in the
>> {pre,post}{inst,rm} stages imho, and is a bit of an abuse of
>> what debconf is designed for. It also means running all of
>> these stages as root.
>
> Indeed, good point.
The last time I checked, prompting user via something other than Debconf
was considered evil.
And how would you avoid running this as root? I do not think you can
rely on some location being writable by non-root at install time.
You also cannot rely on availability of '/tmp' or any other
directory/partition, as it, for example, can be too small, etc.
> I just read recently, while translating on the Debian Installer manual
> about being able to tell the package management that a certain
> application installed from source is providing a functionality (well,
> package name). I wonder if this is by hacking some files or if there
> is a dedicated application which can do this...
Something like 'equivs'? But we are not installing from source here.
>> The tricky bit is the fine line between having lots of hacky
>> code that builds and adjusts packages, or just depending on
>> the proper tool packages and having lots of dependencies :(
>
> Frankly, I don't have a clear picture about in which case the second
> scenario would apply and how is supposed to work.. I would appreciate
> more details.
If we are going to implement an abstract installer, it would need to be
able to unpack every single archive format out there. That would mean
HUGE amount of helper packages pulled in.
Something like a common Debconf template (or some template generator) is
way more sane and doable.
Reply to: