[gentoo-dev] Creation and handling of virtual/tar

[gentoo-dev] Creation and handling of virtual/tar

[Diego 'Flameeyes' Pettenò]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ok before going on with the profile changes for Gentoo/*BSD, I'd like  
to fix the virtual/tar thing. Just to make the things more clear, of  
the current and planned Gentoo/ALT ports, the "tar" command is going  
to be provided by two different packages: app-arch/tar (GNU tar) and  
app-arch/bsdtar (FreeBSD's tar). Both works on many operating   
systems (I was able to port bsdtar to Solaris, too :P) and are syntax  
compatible.
The distribution of them is this:

app-arch/tar is the default for Gentoo Linux, Gentoo Darwin, Gentoo  
OSX, Gentoo DragonFlyBSD
app-arch/bsdtar is the default for Gentoo FreeBSD

It might seem not distributed in the right way, I know, but that's  
what I have right now :P

Right now one can have two different tar commands installed, one as  
gtar and one as bsdtar, and a symlink for tar command depending on  
the CHOST/USERLAND variables. It would be great for people to select  
their own tar command, so that people who wants to use bsdtar instead  
of gtar on Linux can do that without problems.

I already[1] talked about handling compatible alternatives, and I'd  
like to progress with this. Carsten suggestion on that thread is  
actually valid, an eclass would probably solve many problems.

What I want to hear is if anyone has good reasons to not allowing  
choosing the tar command between the two compatible alternatives  
(both works fine with portage). If nobody has reasons, I'll be back  
in a couple of days with eclass, modified ebuilds, and if I can find  
time to learn about it an eselect module to select a generic  
"tool" (tar only in this moment).

The problem right now is registering a list of viable alternatives,  
that would be simple with eselect but the problem might be that  
virtual/tar would be a system package and right now depending on  
eselect might not be the case (when new compiler-config is unmasked,  
the problem probably does not exists anymore).

eselect devs are welcome to slap me if I'm being stupid ;)

[1] http://thread.gmane.org/gmane.linux.gentoo.devel/32099
- --
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFDbslHe2h1+2mHVWMRAo5zAKCrcZaSu/WjM7+VkjNqK6AsBT+tSwCg3gB3
Cdg/gWRjBa0DWYQuaD5KVhs=
=nSaP
-----END PGP SIGNATURE-----

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Creation and handling of virtual/tar

[Donnie Berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Diego 'Flameeyes' Pettenò wrote:
| What I want to hear is if anyone has good reasons to not allowing
| choosing the tar command between the two compatible alternatives  (both
| works fine with portage). If nobody has reasons, I'll be back  in a
| couple of days with eclass, modified ebuilds, and if I can find  time to
| learn about it an eselect module to select a generic  "tool" (tar only
| in this moment).

Sure. What's the point? What benefit does one tar have over the other?
How is bsdtar more capable in any situation than gnutar?

Thanks,
Donnie
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDb5tMXVaO67S1rtsRAj9vAKDA7OQ3FCDDEHSExLuF5zll19EbtACgpSkq
KY35vUu27fks6SktZ5gUEnk=
=6Mlg
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Creation and handling of virtual/tar

[Diego 'Flameeyes' Pettenò]

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

On Monday 07 November 2005 19:22, Donnie Berkholz wrote:
> Sure. What's the point? What benefit does one tar have over the other?
> How is bsdtar more capable in any situation than gnutar?
the first point is not to change the default behavior of an userland, so 
FreeBSD should have FreeBSD tar.

About the difference between the two, I still prefer bsdtar because is a 
little more cleaner (imho), it does not use gzip/bzip2 in pipe to 
extract .tar.gz and .tar.bz2 archives, and it extracts zip files and iso 
files.

And it's a choice people can do, default users won't see any difference 
anyway.

-- 
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] Creation and handling of virtual/tar

[Alec Joseph Warner]

Diego 'Flameeyes' Pettenò wrote:
> On Monday 07 November 2005 19:22, Donnie Berkholz wrote:
> 
>>Sure. What's the point? What benefit does one tar have over the other?
>>How is bsdtar more capable in any situation than gnutar?
> 
> the first point is not to change the default behavior of an userland, so 
> FreeBSD should have FreeBSD tar.
> 
> About the difference between the two, I still prefer bsdtar because is a 
> little more cleaner (imho), it does not use gzip/bzip2 in pipe to 
> extract .tar.gz and .tar.bz2 archives, and it extracts zip files and iso 
> files.
> 
> And it's a choice people can do, default users won't see any difference 
> anyway.
> 

So why is a virtual needed?  Don't the two packages co-exist?
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Creation and handling of virtual/tar

[Diego 'Flameeyes' Pettenò]

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

On Monday 07 November 2005 20:38, Alec Joseph Warner wrote:
> So why is a virtual needed?  Don't the two packages co-exist?
They do, but at the moment just one can provide /bin/tar for a specific 
system.

The idea is to be able to select one of the two, like loggers, crons, and 
similar. And just let virtual/tar be included in the base's packages, 
defaulting base virtual/tar to app-arch/tar, and overwriting it on freebsd 
profiles to app-arch/bsdtar.

And when I want to remove app-arch/tar from linux... I can just select my own 
virtual provider on /etc/portage/profile, and let deps be clear by 
themselves.

-- 
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 --]