[gentoo-dev] Handling compatible multi tools

[gentoo-dev] Handling compatible multi tools

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 1417 bytes --]

Hi everybody,
Please don't start flaming me for this proposal, it's a discussion.

Now, we have in tree app-arch/bsdtar and app-arch/tar (gnu tar) that are 
syntax compatible and can actually work fine on Gentoo/Linux or 
Gentoo/FreeBSD or anything Gentoo/*..

Now they are probably the only two of a series of tools that might be choosen 
from a list.

I already tried preparing a list, but right now, they are probably limited to 
tar and mpg123/mpg321 ... sort of.

What I was thinking of is to standardize a way they can be handled. A part an 
eselect module, what I was thinking of was a way to have (in this 
case) /bin/tar remain what it is if it's a symlink.

Basically, I thought of this:

* don't install the symlink in src_install
* in pkg_postinst, look at ${ROOT}/bin/tar.. if it does exists, and it points 
on something existing, don't touch it, otherwise, make it a link to the 
current tar
* in pkg_postrm, if ${ROOT}/bin/tar points to something non existant, remove 
it

at this point, gnu tar and bsdtar might share a virtual, and one can choose 
the tar to use (obviously, the default remains on the os default tar, so 
bsdtar for freebsd, and gnu tar for everything else).

It's probably incomplete, so I like proposals about this...
-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Handling compatible multi tools

[Simon Stelling]

What would we gain with such a change? You have two tools installed that are 
nearly equal, so why would one want to have two of them?

*me scratching head*

-- 
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
blubb@gentoo.org
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Handling compatible multi tools

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 486 bytes --]

On Friday 14 October 2005 10:17, Simon Stelling wrote:
> What would we gain with such a change? You have two tools installed that
> are nearly equal, so why would one want to have two of them?
Testing, for once.
How many people have both vim and nano installed?
Or xine and mplayer?

I don't see much difference from this to having two tar....

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Handling compatible multi tools

[Simon Stelling]

Diego 'Flameeyes' Pettenò wrote:
> How many people have both vim and nano installed?
> Or xine and mplayer?

well, i wouldn't say nano is doing the same as vi. There's a pretty big 
difference. Also, those people who have both installed probably don't use both, 
they just installed vi and didn't care to remove nano. And about xine/mplayer, 
they're pretty different as well. I'm surely not stopping you from implementing 
your idea, I just lack to see a real benefit.

Regards,

-- 
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
blubb@gentoo.org
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Handling compatible multi tools

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 881 bytes --]

On Friday 14 October 2005 00:33, Diego 'Flameeyes' Pettenò wrote:
> I already tried preparing a list, but right now, they are probably limited
> to tar and mpg123/mpg321 ... sort of.

Add sys-apps/star to your list.

> * don't install the symlink in src_install
> * in pkg_postinst, look at ${ROOT}/bin/tar.. if it does exists, and it
> points on something existing, don't touch it, otherwise, make it a link to
> the current tar
> * in pkg_postrm, if ${ROOT}/bin/tar points to something non existant,
> remove it

The only problem I see with this are concurrent emerge processes (not 
supported now, but hopefully in a future Portage version). Apart from that it 
is a bit ugly to have this code in every affected ebuild, so maybe using a 
CHECK_SYMLINK="${ROOT}/bin/tar" variable and having the rest of the code in 
an eclass would be a good idea.


Carsten

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]