Re: Proposal: Fixing non-free content issues via installer packages
On 14/08/06, Linas Žvirblis <0x0007@gmail.com> wrote:
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.
*I* think that DFSG 4 is more important than most think, and think
that the way is phrased is the way the order should be.
OTOH, it will be not as straight forward to install those data files
as it is with free ones (where apt* is used), so I think it will be
discourging anyway.
>>> 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.
In that case we should look in that direction, right?
>> 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.
Well, that should not stop us from doing it and discouraging even more
people to use it :-P .
>> 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.
It might be, but that is for packages themselves, here we want to
forcibly add some files in the system which can be removed via
"apt-get remove" later.
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.
I guess I forgot that... oops.
> 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.
(after looking at equivs' description) I guess so, thanks.
>> 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.
I was thinking of an abstract installer for data files not in dpkg
format. Something like a thingie that can be fired and then it asks
you what is the URI you want to get the data from, and it would get
the tarball (let's stick to that for now), unpack it, generate
associated meta files for pkg to be made aware of the installed
"package" and its files, so when you run later dpkg -r <datapack> or
apt-get remove <datapack> it will uninstall it and remove its files.
Bonus: if you use dpkg-repack, you will obtain a deb which can be used
later ;-) .
Something like a common Debconf template (or some template generator) is
way more sane and doable.
Depends a lot on what you are thinging about.
--
Regards,
EddyP
=============================================
"Imagination is more important than knowledge" A.Einstein
Reply to: