Alec Warner wrote:
> On Mon, Mar 16, 2009 at 8:39 PM, Ravi Pinjala <ravi@...> wrote:
>> One of my occasional frustrations with Gentoo is that it's more
>> difficult than it needs to be to install a package from a tarball, and
>> still have its files tracked by a package manager. The simplest thing
>> I've found to do is to create an ebuild in my personal overlay and use
>> that, but not everybody wants/needs to learn how to write ebuilds.
>> My project idea is a tool to allow users to quickly install packages
>> from tarballs, or other sources, and have the installed files tracked by
>> their package manager. Ideally, it should be no more difficult than the
>> usual "./configure; make; make install" sequence that we're all used to.
> ebuild with blank src_unpack, blank src_compile, src_install that
> unpacks the tarball into $D
> config files and whatnot are difficult.
Well, it'd be nice to compile the package too, but point taken. :p
Even so, that still requires the user to know something about ebuild
writing, and maintain a personal overlay. People are much more likely to
already know how to install packages from source tarballs; it ought to
be possible to install a package (and have the PM be aware of it) using
just that knowledge.
>> One obvious issue with this is dependencies; if packages installed using
>> this method can be used as dependencies of other packages, it makes it a
>> lot easier for users to do strange things to their systems. My initial
>> instinct is to say that packages installed by this method will be
>> excluded from dependency calculations somehow, but I also think the
>> option should be there somewhere.
> I don't see how its much different than using any other binary package.
I'm actually not sure how Gentoo binary packages work. If they're just
tarballs of the files a package installs, then yeah, it's very similar.
I'm assuming they have more information than that, though, since USE
deps, for example, would be useless otherwise.
Official binary packages also have the advantage of having been checked
by a developer. The situation I'm trying to avoid here is that a user
installs package A through this method, then installs package B which
depends on A, through portage. If the user has done something strange
with A, B could fail in interesting ways, and it would not be at all
obvious that A was the problem.
>> Questions/comments/suggestions? Is this actually a terrible idea, for
>> reasons I haven't thought of yet? :)