Mailing List Archive: Gentoo: OSX

zip, and more, in package.provided

Index | Next | Previous | View Threaded

gongloo at gentoo

Feb 1, 2005, 10:57 AM

Post #1 of 11 (887 views)
Permalink

zip, and more, in package.provided

All right guys, there are now a few packages out there that we need to
somehow put in package.provided, or otherwise provide for them in
portage. The catch is that many of these packages are not the (Gentoo
default) gnu version, but rather the BSD version. app-arch/zip comes to
mind, but there are others.

If the API for the package is consistent with the gnu version, by
Gentoo for Mac OS X policy, we put the package in package.provided with
a comparable version number/string.

We do not yet have policy for packages that are provided by Apple and
that have a different API than that of the gnu version. I'm opening up
the floor here for discussion on this.

What comes immediately to mind is making the said packages a virtual,
and then satisfying the virtual in our profile. This should work most
of the time, as most packages that use, for example, zip, do not use
any of the arguments that differ between the gnu and BSD versions.

--
Hasan Khalil
Ebuild/Porting Co-Lead
Gentoo for Mac OS X

PGP Key: 0x707B8F18 on pgp.mit.edu

Attachments:

PGP.sig (0.18 KB)

ndimiduk at gentoo

Feb 2, 2005, 5:01 AM

Post #2 of 11 (864 views)
Permalink

Re: zip, and more, in package.provided [In reply to]

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

Hasan Khalil wrote:
| We do not yet have policy for packages that are provided by Apple and
| that have a different API than that of the gnu version. I'm opening up
| the floor here for discussion on this.

Virtuals would seem to be the method to use which fits most seamlessly
into portage. On the other hand, if the API to BSD package is
significantly different from the GNU package I would suggest duplicating
the functionality of the (g)sed ebuild.

How many packages are we going to have to apply these changes to?
Should we use a gwrapper.eclass to make something like this easier to
maintain?

- -Nick Dimiduk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCAMERMRGACoLVQ1kRAjDbAKCSzCVojq9hV9ODKD2cApXUyxtGxQCZAYos
1eRyRovLpIcKxAx1dzxJv8A=
=hbGO
-----END PGP SIGNATURE-----

--
gentoo-osx [at] gentoo mailing list

ft01 at webmastery

Feb 2, 2005, 7:08 AM

Post #3 of 11 (865 views)
Permalink

Re: zip, and more, in package.provided [In reply to]

On Tue, 1 Feb 2005, Hasan Khalil wrote:

> ...
>
> We do not yet have policy for packages that are provided by Apple and that
> have a different API than that of the gnu version. I'm opening up the floor
> here for discussion on this.

Well, first, write the ebuild for the BSD version :-)

> What comes immediately to mind is making the said packages a virtual, and
> then satisfying the virtual in our profile.

Yes. You just use the BSD one for a macos profile, and the GNU one for a
linux profile.

I'm not completely serious about writing ebuilds for all of Apple's stuff
we depend on. I wrote to this list with a rant about "vendor" packages a
while back, to address exactly this problem. But, since OpenSolaris is out
now, it seems a bit irrelevant.

This is probably just a naming convention issue, i.e. what do you call
Apple's cpio, Sun's cpio, etc in order to add them to package.provided and
thus satisfy the virtual.

It gets interesting because, someday, someone will write an ebuild for
Darwin's cpio, and it will be the same as the OS X one. So, one might ask,
what are they going to call their ebuild & category, and I'll just put
that in package.provided.

> This should work most of the time, as most packages that use, for
> example, zip, do not use any of the arguments that differ between the
> gnu and BSD versions.

Yep, in those cases, you change the dep to be the virtual, and save some
time and space by using the already present (Apple) one.

The problem arises when a package really needs the GNU version -- you
can't just specify that as a dep, since the GNU one will clobber the Apple
one, and people will get terribly upset. Or will it? Doesn't pathspec
permit both versions to be installed?

-f

--
gentoo-osx [at] gentoo mailing list

nathan.stocks at gmail

Feb 2, 2005, 7:57 AM

Post #4 of 11 (861 views)
Permalink

Re: zip, and more, in package.provided [In reply to]

Didn't something special get implemented for libtool on the linux
side? i.e. Isn't there about a ten different versions of it, and
they're all installed, and there's a way for ebuilds to call the one
they want? Could this be applied in a more general manner, or is this
an ugly hack?

On Thu, 3 Feb 2005 01:08:12 +1100 (EST), Finn Thain
<ft01 [at] webmastery> wrote:
>
>
> On Tue, 1 Feb 2005, Hasan Khalil wrote:
>
> > ...
> >
> > We do not yet have policy for packages that are provided by Apple and that
> > have a different API than that of the gnu version. I'm opening up the floor
> > here for discussion on this.
>
> Well, first, write the ebuild for the BSD version :-)
>
> > What comes immediately to mind is making the said packages a virtual, and
> > then satisfying the virtual in our profile.
>
> Yes. You just use the BSD one for a macos profile, and the GNU one for a
> linux profile.
>
> I'm not completely serious about writing ebuilds for all of Apple's stuff
> we depend on. I wrote to this list with a rant about "vendor" packages a
> while back, to address exactly this problem. But, since OpenSolaris is out
> now, it seems a bit irrelevant.
>
> This is probably just a naming convention issue, i.e. what do you call
> Apple's cpio, Sun's cpio, etc in order to add them to package.provided and
> thus satisfy the virtual.
>
> It gets interesting because, someday, someone will write an ebuild for
> Darwin's cpio, and it will be the same as the OS X one. So, one might ask,
> what are they going to call their ebuild & category, and I'll just put
> that in package.provided.
>
> > This should work most of the time, as most packages that use, for
> > example, zip, do not use any of the arguments that differ between the
> > gnu and BSD versions.
>
> Yep, in those cases, you change the dep to be the virtual, and save some
> time and space by using the already present (Apple) one.
>
> The problem arises when a package really needs the GNU version -- you
> can't just specify that as a dep, since the GNU one will clobber the Apple
> one, and people will get terribly upset. Or will it? Doesn't pathspec
> permit both versions to be installed?
>
> -f
>
> --
> gentoo-osx [at] gentoo mailing list
>
>

--
gentoo-osx [at] gentoo mailing list

kito at gentoo

Feb 3, 2005, 11:30 AM

Post #5 of 11 (859 views)
Permalink

Re: zip, and more, in package.provided [In reply to]

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

On Feb 1, 2005, at 11:57 AM, Hasan Khalil wrote:

> All right guys, there are now a few packages out there that we need to
> somehow put in package.provided, or otherwise provide for them in
> portage. The catch is that many of these packages are not the (Gentoo
> default) gnu version, but rather the BSD version. app-arch/zip comes
> to mind, but there are others.
>
> If the API for the package is consistent with the gnu version, by
> Gentoo for Mac OS X policy, we put the package in package.provided
> with a comparable version number/string.
>
> We do not yet have policy for packages that are provided by Apple and
> that have a different API than that of the gnu version. I'm opening up
> the floor here for discussion on this.
>
> What comes immediately to mind is making the said packages a virtual,
> and then satisfying the virtual in our profile. This should work most
> of the time, as most packages that use, for example, zip, do not use
> any of the arguments that differ between the gnu and BSD versions.

This probably isn't the sort of response you were soliciting, but I
think if we identify some 'big picture' goals of the project it might
aid in "seeing the forest through the trees" so to speak.

Here are some possible scenarios:

1) user has an existing OS X install, with portage living in an
arbitrary prefix i.e. fink, darwinports. nothing outside the prefix is
ever modified . This of course, relies on pathspec and its
implementation. To take this even farther, dynamic USERLAND could be
possible, i.e. ability to switch between *bsd, GNU, darwin, etc.

2) user has an existing OS X install, portage lives in /, packages are
installed without overwriting Apple provided files i.e.
FEATURES="-collision-protect". This of course, is our current state.

3) user has an existing OS X install, portage lives in /, apple
provided packages may be replaced by packages in portage. Depending on
the users wants/needs, several options present themselves i.e.
converting the base system and/or utilities to opendarwin, GNU, or *BSD
while retaining all proprietary libs and frameworks.

4) user installs from Gentoo media. The user performs a system install
from our media(LiveCD,netboot,whatever), interactive installation of
the base system with the choice of USERLANDs. Once the base system is
installed, something like 'emerge macosx' should be possible, i.e.
install the apple proprietary libs and frameworks alongside the gentoo
system.

A good portion of this could be handled through creative profile
manipulation and/or additional keywords/userlands.

Ok, sorry for rambling, just thought I'd throw that into the discussion.

Regards,

Kito

>
> --
> Hasan Khalil
> Ebuild/Porting Co-Lead
> Gentoo for Mac OS X
>
> PGP Key: 0x707B8F18 on pgp.mit.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (Darwin)

iD8DBQFCAm3UJ0rMK/3OwgsRAviCAJ9au+aX8FlPYUCI2GnQocDQNiqPfACeOR58
SOMR7iqpTH+dQQxsdrXtENc=
=3l5g
-----END PGP SIGNATURE-----

--
gentoo-osx [at] gentoo mailing list

lists at anderedomain

Feb 3, 2005, 3:10 PM

Post #6 of 11 (861 views)
Permalink

Re: zip, and more, in package.provided [In reply to]

On 3. Feb 2005, at 19:30 Uhr, Kito wrote:

> 1) user has an existing OS X install, with portage living in an
> arbitrary prefix i.e. fink, darwinports. nothing outside the prefix is
> ever modified . This of course, relies on pathspec and its
> implementation. To take this even farther, dynamic USERLAND could be
> possible, i.e. ability to switch between *bsd, GNU, darwin, etc.

As soon as that is possible i will install gentoo-macos on my iBook and
do as much as i can to help.

-stoile

--
gentoo-osx [at] gentoo mailing list

gongloo at gentoo

Feb 3, 2005, 4:25 PM

Post #7 of 11 (864 views)
Permalink

Re: zip, and more, in package.provided [In reply to]

On Feb 3, 2005, at 13:30, Kito wrote:
> 1) user has an existing OS X install, with portage living in an
> arbitrary prefix i.e. fink, darwinports. nothing outside the prefix is
> ever modified . This of course, relies on pathspec and its
> implementation. To take this even farther, dynamic USERLAND could be
> possible, i.e. ability to switch between *bsd, GNU, darwin, etc.

We're still waiting for pvdabeel's description of how pathspec will
work for this... I'd like to begin migratory work on it in anticipation
of pathspec's 'release', but this is obviously impossible until we're
filled in.

> 3) user has an existing OS X install, portage lives in /, apple
> provided packages may be replaced by packages in portage. Depending on
> the users wants/needs, several options present themselves i.e.
> converting the base system and/or utilities to opendarwin, GNU, or
> *BSD while retaining all proprietary libs and frameworks.

Our current stance is not to support this scenario, and I don't foresee
any change in this stance. From the QA standpoint, it just becomes a
nightmare.

> 4) user installs from Gentoo media. The user performs a system install
> from our media(LiveCD,netboot,whatever), interactive installation of
> the base system with the choice of USERLANDs. Once the base system is
> installed, something like 'emerge macosx' should be possible, i.e.
> install the apple proprietary libs and frameworks alongside the gentoo
> system.

Just to confirm, this is what we mean by gentoo-darwin (or whatever we
want to call Gentoo on a Darwin base system), right?
--
Hasan Khalil
Ebuild/Porting Co-Lead
Gentoo for Mac OS X

PGP Key: 0x707B8F18 on pgp.mit.edu

Attachments:

PGP.sig (0.18 KB)

gongloo at gentoo

Feb 3, 2005, 4:34 PM

Post #8 of 11 (861 views)
Permalink

Re: zip, and more, in package.provided [In reply to]

On Feb 2, 2005, at 09:57, Nathan wrote:

> Didn't something special get implemented for libtool on the linux
> side? i.e. Isn't there about a ten different versions of it, and
> they're all installed, and there's a way for ebuilds to call the one
> they want? Could this be applied in a more general manner, or is this
> an ugly hack?

It's called 'slotting'. Read up on it and you'll see that it won't help
us -- it would still require replacing Apple-provided files.

Attachments:

PGP.sig (0.18 KB)

gongloo at gentoo

Feb 3, 2005, 4:40 PM

Post #9 of 11 (864 views)
Permalink

Re: zip, and more, in package.provided [In reply to]

On Feb 2, 2005, at 07:01, Nick Dimiduk wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hasan Khalil wrote:
> | We do not yet have policy for packages that are provided by Apple and
> | that have a different API than that of the gnu version. I'm opening
> up
> | the floor here for discussion on this.
>
> Should we use a gwrapper.eclass to make something like this easier to
> maintain?

No can do. If the work were reproducible in an automated fashion over
various packages, this would already have been done. The work done
differs per package. Perl, for example, is either impossible to make a
g<util> out of, or would take more coaxing than we're interested in.
Pretty much anything that installs libraries is out of the g<util>
scope, unless someone has an idea of how to get around that.

--
Hasan Khalil
Ebuild/Porting Co-Lead
Gentoo for Mac OS X

PGP Key: 0x707B8F18 on pgp.mit.edu

Attachments:

PGP.sig (0.18 KB)

kito at gentoo

Feb 4, 2005, 11:00 AM

Post #10 of 11 (861 views)
Permalink

Re: zip, and more, in package.provided [In reply to]

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

On Feb 3, 2005, at 5:25 PM, Hasan Khalil wrote:

>
> On Feb 3, 2005, at 13:30, Kito wrote:
>> 1) user has an existing OS X install, with portage living in an
>> arbitrary prefix i.e. fink, darwinports. nothing outside the prefix
>> is ever modified . This of course, relies on pathspec and its
>> implementation. To take this even farther, dynamic USERLAND could be
>> possible, i.e. ability to switch between *bsd, GNU, darwin, etc.
>
> We're still waiting for pvdabeel's description of how pathspec will
> work for this... I'd like to begin migratory work on it in
> anticipation of pathspec's 'release', but this is obviously impossible
> until we're filled in.
>
>> 3) user has an existing OS X install, portage lives in /, apple
>> provided packages may be replaced by packages in portage. Depending
>> on the users wants/needs, several options present themselves i.e.
>> converting the base system and/or utilities to opendarwin, GNU, or
>> *BSD while retaining all proprietary libs and frameworks.
>
> Our current stance is not to support this scenario, and I don't
> foresee any change in this stance. From the QA standpoint, it just
> becomes a nightmare.

Well, if we are talking details, macos itself is not an officially
supported project. I'm not talking about accepting bugs for Mail.app
because someone has portage installed. And as far as the QA issue, it
would IMO actually be *easier* to do QA and bugsquashing as most if not
all of the toolchain would be from portage, most of the big problems we
face now are dealing with Apples toolchain and our policy not to
overwrite provided files.

>
>> 4) user installs from Gentoo media. The user performs a system
>> install from our media(LiveCD,netboot,whatever), interactive
>> installation of the base system with the choice of USERLANDs. Once
>> the base system is installed, something like 'emerge macosx' should
>> be possible, i.e. install the apple proprietary libs and frameworks
>> alongside the gentoo system.
>
> Just to confirm, this is what we mean by gentoo-darwin (or whatever we
> want to call Gentoo on a Darwin base system), right?

As a user, myself and several others I've talked to want the ability
use portage in any of these scenarios. This by no means implies devs
are forced to develop it, or users are forced to use it. People work on
what interests them. I don't touch any x11 related packages, because I
don't use them, don't want to support them, don't care. I have a great
personal interest in implementing scenarios 2-4. I never had a great
interest in trying to duplicate the work of Fink and Darwinports, and
didn't join the project to start doing so.

I was mostly presenting these ideas just so we could take into
consideration directions we might go in the future, so any solution
we/you/I/them come up with will be scalable and a high return on
investment so to speak.

So, that being said, it is my intention to introduce a profile in
default-darwin/ and a new keyword that will allow users to install
packages on a Mac OS X system, even if they overwrite vendor provided
files. Mind you I said intention, if everyone and their mother thinks
its the worst idea in the history of gentoo, of course I won't do it.

> --
> Hasan Khalil
> Ebuild/Porting Co-Lead
> Gentoo for Mac OS X
>
> PGP Key: 0x707B8F18 on pgp.mit.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (Darwin)

iD8DBQFCA7gtJ0rMK/3OwgsRAnmUAKC8uHdMjdCxc7K8kFja2Hk4rlTuvQCeOJx2
Saajmeb04/RfJonrDnaXzgM=
=v/qd
-----END PGP SIGNATURE-----

--
gentoo-osx [at] gentoo mailing list

kito at gentoo

Feb 7, 2005, 10:30 AM

Post #11 of 11 (862 views)
Permalink

Re: zip, and more, in package.provided [In reply to]

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

I sent this on the 3rd, long before our irc meeting on #-osx, please
ignore. dont know why it just came through now :/
On Feb 4, 2005, at 12:00 PM, Kito wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On Feb 3, 2005, at 5:25 PM, Hasan Khalil wrote:
>
>>
>> On Feb 3, 2005, at 13:30, Kito wrote:
>>> 1) user has an existing OS X install, with portage living in an
>>> arbitrary prefix i.e. fink, darwinports. nothing outside the prefix
>>> is ever modified . This of course, relies on pathspec and its
>>> implementation. To take this even farther, dynamic USERLAND could be
>>> possible, i.e. ability to switch between *bsd, GNU, darwin, etc.
>>
>> We're still waiting for pvdabeel's description of how pathspec will
>> work for this... I'd like to begin migratory work on it in
>> anticipation of pathspec's 'release', but this is obviously
>> impossible until we're filled in.
>>
>>> 3) user has an existing OS X install, portage lives in /, apple
>>> provided packages may be replaced by packages in portage. Depending
>>> on the users wants/needs, several options present themselves i.e.
>>> converting the base system and/or utilities to opendarwin, GNU, or
>>> *BSD while retaining all proprietary libs and frameworks.
>>
>> Our current stance is not to support this scenario, and I don't
>> foresee any change in this stance. From the QA standpoint, it just
>> becomes a nightmare.
>
> Well, if we are talking details, macos itself is not an officially
> supported project. I'm not talking about accepting bugs for Mail.app
> because someone has portage installed. And as far as the QA issue, it
> would IMO actually be *easier* to do QA and bugsquashing as most if
> not all of the toolchain would be from portage, most of the big
> problems we face now are dealing with Apples toolchain and our policy
> not to overwrite provided files.
>
>>
>>> 4) user installs from Gentoo media. The user performs a system
>>> install from our media(LiveCD,netboot,whatever), interactive
>>> installation of the base system with the choice of USERLANDs. Once
>>> the base system is installed, something like 'emerge macosx' should
>>> be possible, i.e. install the apple proprietary libs and frameworks
>>> alongside the gentoo system.
>>
>> Just to confirm, this is what we mean by gentoo-darwin (or whatever
>> we want to call Gentoo on a Darwin base system), right?
>
> As a user, myself and several others I've talked to want the ability
> use portage in any of these scenarios. This by no means implies devs
> are forced to develop it, or users are forced to use it. People work
> on what interests them. I don't touch any x11 related packages,
> because I don't use them, don't want to support them, don't care. I
> have a great personal interest in implementing scenarios 2-4. I never
> had a great interest in trying to duplicate the work of Fink and
> Darwinports, and didn't join the project to start doing so.
>
> I was mostly presenting these ideas just so we could take into
> consideration directions we might go in the future, so any solution
> we/you/I/them come up with will be scalable and a high return on
> investment so to speak.
>
> So, that being said, it is my intention to introduce a profile in
> default-darwin/ and a new keyword that will allow users to install
> packages on a Mac OS X system, even if they overwrite vendor provided
> files. Mind you I said intention, if everyone and their mother thinks
> its the worst idea in the history of gentoo, of course I won't do it.
>
>> --
>> Hasan Khalil
>> Ebuild/Porting Co-Lead
>> Gentoo for Mac OS X
>>
>> PGP Key: 0x707B8F18 on pgp.mit.edu
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (Darwin)
>
> iD8DBQFCA7gtJ0rMK/3OwgsRAnmUAKC8uHdMjdCxc7K8kFja2Hk4rlTuvQCeOJx2
> Saajmeb04/RfJonrDnaXzgM=
> =v/qd
> -----END PGP SIGNATURE-----
>
>
> --
> gentoo-osx [at] gentoo mailing list
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (Darwin)

iD8DBQFCB6WxJ0rMK/3OwgsRAs0QAJ9dAgg8EQh+SdmfL4shxSJi1X3uMQCgjcm9
t/D8ec2FXRiq9jYTy1AJsog=
=EoH8
-----END PGP SIGNATURE-----

--
gentoo-osx [at] gentoo mailing list

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads