Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 311707 - sys-apps/portage: support .deb/.rpm package formats
Summary: sys-apps/portage: support .deb/.rpm package formats
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Conceptual/Abstract Ideas (show other bugs)
Hardware: All All
: High enhancement (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-28 03:25 UTC by dE
Modified: 2010-09-11 07:50 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description dE 2010-03-28 03:25:17 UTC
Ubuntu being the most used distribution around; one will most probably find it's corresponding deb packages of a software which is not in portage but is required by a Gentoo user. RPM comes second, but probability of an ebuild is very less.


Cause of this reason, I think it's a good idea to make portage roughly support deb and/or rpm packages.

To install a package, one has to specify the location of the deb or rpm file or place the package to a specified place (which will depend on the variable in make.conf).

Portage will read it's dependencies and install the respective package, if the package is not there in portage, the user will have to specify the alternative package available in portage but not with that specific name...I'm taking about substitution of these packages.
debian and RPM repositories also contain the dev packages which might be required by users...to install these packages, the USE will have to be altered by the user.

Alternatively portage will be able to force install without the dependencies.

The reason why I'm preferring this over conversion to tar.gz is cause on doing so, portage does not record the files that were placed and so one has to remove the package by hand.

Reproducible: Always

Steps to Reproduce:
Comment 1 Jeremy Olexa (darkside) (RETIRED) archtester gentoo-dev Security 2010-03-28 03:33:47 UTC
(In reply to comment #0)
> The reason why I'm preferring this over conversion to tar.gz is cause on doing
> so, portage does not record the files that were placed and so one has to remove
> the package by hand.

I don't quite understand this statement. If you convert[1] the deb/rpm to tar.gz first, then you can write an ebuild just like normal and have portage track it's installation. So, the big question becomes "Why should so much time be invested to support (and maintain!) another package format??"

[1]:
app-arch/rpm2targz
app-arch/deb2targz
Comment 2 dE 2010-03-28 03:40:03 UTC
non-developers can't make ebuilds.


Speaking of which I was searching for an ebuild generator but did not find any.
Comment 3 Jeremy Olexa (darkside) (RETIRED) archtester gentoo-dev Security 2010-03-28 03:51:43 UTC
(In reply to comment #2)
> non-developers can't make ebuilds.

There is a saying like that, "Give a man a fish, feed him for a day. Teach him how to fish and feed him for life"

We are not a deb/rpm based distribution, we shouldn't pretend like it. There are plenty of support vehicles for "non-devs to learn ebuilds" like, http://devmanual.gentoo.org, irc (#gentoo-dev-help), mailing lists (gentoo-devhelp@lists.gentoo.org), etc.
Comment 4 dE 2010-03-28 04:03:16 UTC
The effort required is not that less.

Learning portage, the Gentoo starup scripts etc... is not that hard for non devs but to make ebuilds you need to know shell scripting. I don't have any problems learning shell (I do have a small idea though), but will other do it?

Gentoo users don't need to learn programming; so shell scripting should be completely optional. It requires time to learn and make and ebuild, possibly it requires less user attention to learn and install Gentoo.

What I mean is that there there's a difference between a developer and an even an advanced Linux user.

Alternatively, one can make a script to generate ebuilds from the converted tar.gz and putting it into portage.
Comment 5 dE 2010-03-28 04:06:05 UTC
Portage does not need to support deb completely, but it should at least extract them and install without the dependencies and record it as an installation.
Comment 6 Zac Medico gentoo-dev 2010-03-28 05:17:28 UTC
(In reply to comment #5)
> Portage does not need to support deb completely, but it should at least extract
> them and install without the dependencies and record it as an installation.

It's trivial to write an ebuild that does this, and using an ebuild has the advantage that you can specify the dependencies. Maybe we just need some documentation (like a short HOWTO document) that is targeted at this specific kind of (trivial) case.
Comment 7 Brian Harring (RETIRED) gentoo-dev 2010-03-28 05:41:26 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > Portage does not need to support deb completely, but it should at least extract
> > them and install without the dependencies and record it as an installation.
> 
> It's trivial to write an ebuild that does this, and using an ebuild has the
> advantage that you can specify the dependencies. Maybe we just need some
> documentation (like a short HOWTO document) that is targeted at this specific
> kind of (trivial) case.

And would integrate rather poorly into gentoo since the deb/rpm is built against a different ABI universe.  There are exceptions to this (primarily proprietary rpm's that already compensate for this), but by and large, this is a waste of gentoo's time via gross lack of understanding of the issues inherent.  I'll just skip over the whole issue of the pkg integrating into the gentoo ecosystem also (exercise for the reporter, that one).

There is a reason rpm doesn't natively support debs, and vice versa (note I said natively- alien exists but also has a nice long caveat list).  Further, those formats are *binary* targetted- gentoo happens to be source targeted, transitioning from source pkgs to binary is easier then in reverse.

Short version: if you want ubuntu, use ubuntu.
Comment 8 dE 2010-03-28 08:10:45 UTC
Ok, the feature might not be integrated into portage. So we should atleast have a documentation or a separate shell script in the tree which does this.
Comment 10 dE 2010-03-28 08:26:19 UTC
Ok then, a documentation is the perfect idea. But it should be very quick and easy.

Actually there can be a prototype ebuild which has to be edited to make it work with any converted .tar.gz package.

Again the idea of a shell script will be better. It will ask certain questions about the tar.gz file and make the ebuild.
Comment 11 dE 2010-03-28 08:54:31 UTC
Just wondering -- how about integrating this feature with the binary package support which is currently present in portage?
Comment 12 Zac Medico gentoo-dev 2010-03-28 09:17:29 UTC
I'm pretty sure that anyone who's written an ebuild would agree that this kind of thing isn't really appropriate for automation. Things like CPAN perl modules are definitely worth building bridges for, but not deb or rpm due to ABI issues that have already been mentioned. So, I think the best we can do here is to create a guide that's specifically targeted at writing ebuilds which are similar to the ca-certificates and urw-fonts ebuilds that are linked above.
Comment 13 Zac Medico gentoo-dev 2010-03-28 09:23:41 UTC
Actually, (In reply to comment #12)
> Things like CPANCPAN perl modules
> are definitely worth building bridges for, but not deb or rpm due to ABI issues
> that have already been mentioned.

I'm not saying that an rpm or deb bridge would be completely worthless (I bet you'd use it), but I doubt that it would get much use overall and probably wouldn't be worth the effort.
Comment 14 dE 2010-03-28 10:24:01 UTC
But there are many applications that are not specified to a single ABI.... This feature will benefit those. So till now we have discussed 3 solutions - 

1) Integrate this feature into portage. Portage will show the dependencies that is not available in portage and there will be an option to force install.

+ Will make portage install many deps and rpms which are currently available (for e.g. recoll which's not in portage although we do have a volunteer to maintain it. Another e.g -- kat, google desktop etc...). Actually it will be the first package manager to incorporate such a feature.
+ Easiest to the users.
- Problems when the program is highly specific to an ABI. But this will still pose advantage on many binary packages like peazip (I know there's an ebuild).
- No ways to fix the bug.
- Portage will incorporate a broken feature. A feature which is not perfect.

1.1) Integrate this feature partially into portage. i.e all portage will do is unpack the dep and place it the corresponding places; it will be assumed that the dependencies have been taken care off by the user.

+ Comparatively easier to implement.
- Users will have to keep a track of the dependencies. 
- depclean won't work making package management harder.
- Portage will incorporate a broken feature. A feature which is not perfect.

2) Make a documentation on how to make an ebuild to commence installation in portage.

+ If the user is aware of the fixes he can fix it.
+ Load off the devs -- no modification to portage.
+ Portage will not incorporate broken features.
- Gentoo users who are not coders will be in big trouble. This is not like editing configuration files and setting up things; it's like complete 'development'. The administrators will have to develop to get the package working. This is no doubt hardest on the users.

3) Make a shell script to make a generic ebuild asking a few questions about dependencies, customizations etc....

+ Load off the devs -- no modification to portage.
+ Easy for Gentoo users also, they can handle such sort of questions.
+ Portage will not incorporate broken features.
+ Ebuild can be modified by hand to fix bugs later on.

1, 2, 3 (common problem) - 

- Will not work for all packages.
Comment 15 dE 2010-03-28 10:33:31 UTC
I go for 3. This is the best option.


Will it be worth it? IMO moderately. There are many packages that portage does not have; moreover it's hard to get a package into to main tree even if we do find a maintainer. Moreover how many deb packages are not compatible with Gentoo's ABI?

If the devs think it's not worth it, put it on low priority...but this idea is no doubt handy. This script will be like alien for Gentoo.
Comment 16 Zac Medico gentoo-dev 2010-03-28 11:23:05 UTC
(In reply to comment #15)
> I go for 3. This is the best option.
> 
> 
> Will it be worth it? IMO moderately. There are many packages that portage does
> not have; moreover it's hard to get a package into to main tree even if we do
> find a maintainer. Moreover how many deb packages are not compatible with
> Gentoo's ABI?

ABI varies between individual package versions, so it's a matter of which versions of each required library are being used on both distros. You're not familiar with the issues, so you're overestimating how useful such a script would be.

> If the devs think it's not worth it, put it on low priority...but this idea is
> no doubt handy. This script will be like alien for Gentoo.

Well, we're not stopping you from writing and maintaining such a script. We just don't want to be involved with it.
Comment 17 Brian Harring (RETIRED) gentoo-dev 2010-03-28 18:31:52 UTC
Being a bit through on this one...

(In reply to comment #14)
> But there are many applications that are not specified to a single ABI.... This
> feature will benefit those. So till now we have discussed 3 solutions - 
> 
> 1) Integrate this feature into portage. Portage will show the dependencies that
> is not available in portage and there will be an option to force install.

To show these dependencies requires cross distro translation of depdendencies (what is openssl within debian vs gentoo vs fedora, did you want libraries only or are you trying to do builds thus requiring dev and subpkg compaction, etc),  hoping/praying that ABI is compatible, uid/gid importation, and disallowing any phase functions from the target format thus breaking anything that has to do post merge integration (pkgs that install desktop files is but one example).

And also metadata read support for debs and rpms.  Not the simplest of tasks.

That's just off the top of my head- reasonably sure I'm glossing over a few other deal breakers.

> + Will make portage install many deps and rpms which are currently available
> (for e.g. recoll which's not in portage although we do have a volunteer to
> maintain it. Another e.g -- kat, google desktop etc...).

Note those potential maintainers should do the same thing they would do for any other distro- maintain the pkg in the native pkging format for that distro.

Note also that overlays exist for people to bundle ebuilds that the mainline tree doesn't wish to maintain- your peazip is a perfect example.  The build framework is horrendous on it, a binary ebuild tucked away in an overlay is a fair bit more likely than it landing in -x86.


About the only proposal that is sane for stuff like this is an importer- a pkg tool that is fed the metadata to use for the pkg and a pathway to the offset unpacked source, resulting in either a tbz2 or an injection into the vdb (w/ the appropriate offset merge done).

If folks want autotranslation of deps, they have to do it themselves.  They're also quite obviously on their own when it comes to supporting the resultant binpkg/merge.

Such a *generic* tool is a fair bit better then the options presented here, although I consider such a tool still rarely useful...
Comment 18 Jeff Johnson 2010-09-09 15:58:19 UTC
https://bugs.launchpad.net/gentoo/+bug/634163
Comment 19 dE 2010-09-11 07:50:45 UTC
(In reply to comment #18)
> https://bugs.launchpad.net/gentoo/+bug/634163
> 

So is launchpad turning to the official bug reporting system for Gentoo?


If so, that's bad. It's specially designed for Ubuntu and it's users.