headers
Jeremy C. Reed | 1 Aug 2003 01:03

Re: Consistent "Optional Dependecy" handling

On Fri, 1 Aug 2003, Julio M. Merino Vidal wrote:

> And you are screwed up with binary packages.  This is all wonderful when
> using pkgsrc directly, but how do you tell if foobar-1.0.tgz in the ftp
> include gtk support or not?  And, if it included gtk by default, what
> happens if you don't need it and don't want to rebuilt the package?
> etcetera...  (though in some cases they are really necessary...)

We already do offer that feature (and yes, it could be a problem).

The OpenBSD "FLAVOR" like solution would be for the name of the package to
change too (i.e. add "-gtk" to the filename and maybe also package name).

And in another message on Thu, 31 Jul 2003, Nate Hill wrote:

> Okay, so after learning some more about pkgsrc, I have a slight and
> rough proposal:
>
> Standardize the USE* variables in bsd.pkg.defaults.mk:
>
> USE_FOO		<- generic YES|NO flag for feature FOO

Yes.

> USE_FOO_FOO2	<- use feature FOO2 for package FOO (specific quirks)

I think that the standard is to use the PACKAGE_USE_FOO (package name
first).

> Allow package Makefiles to use conditional statements based on USE
(Continue reading)

Permalink | Reply | 7 comments |
headers
Nate Hill | 1 Aug 2003 01:18
Picon
Favicon

Re: Consistent "Optional Dependecy" handling

On Thu July 31 2003 18:03, you wrote:
> On Fri, 1 Aug 2003, Julio M. Merino Vidal wrote:
> > And you are screwed up with binary packages.  This is all
> > wonderful when using pkgsrc directly, but how do you tell if
> > foobar-1.0.tgz in the ftp include gtk support or not?  And, if it
> > included gtk by default, what happens if you don't need it and
> > don't want to rebuilt the package? etcetera...  (though in some
> > cases they are really necessary...)
>
> We already do offer that feature (and yes, it could be a problem).
>
> The OpenBSD "FLAVOR" like solution would be for the name of the
> package to change too (i.e. add "-gtk" to the filename and maybe
> also package name).

Yes, I also realized that this problem exits as we speak. Basically, 
binary packages reflect the settings in defaults.mk. Of course, doing 
something as big as isolating GTK1-v-GTK2 support will make this 
problem obvious (NetBSD will have to decide which to use by default). 
I think the FLAVOR solution sounds good...

> And in another message on Thu, 31 Jul 2003, Nate Hill wrote:
> > Okay, so after learning some more about pkgsrc, I have a slight
> > and rough proposal:
> >
> > Standardize the USE* variables in bsd.pkg.defaults.mk:
> >
> > USE_FOO		<- generic YES|NO flag for feature FOO
>
> Yes.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Nate Hill | 1 Aug 2003 01:32
Picon
Favicon

Re: Consistent "Optional Dependecy" handling

On Thu July 31 2003 18:03, Jeremy C. Reed wrote:
> On Fri, 1 Aug 2003, Julio M. Merino Vidal wrote:
> > ...
> And in another message on Thu, 31 Jul 2003, Nate Hill wrote:
> > ...
> > Being able to set USE_GTK = NO in mk.conf would be extremely
> > useful...
>
> Need to find a developer who has the time to do this. Hopefully,
> you can provide some patches.

Okay, I see that there is already a USE_OSS flag (which is undefined 
default) and it is checked in kdemultimedia3:

.if defined(USE_OSS)
CONFIGURE_ARGS+=        --enable-audio=oss
.endif

My question is wether I can implement this by just adding a USE_GTK 
flag in bsd.pkg.defaults.mk? Is there some kludge that needs changing 
elsewhere?

If I can add the USE_GTK option that simply then, I can muck with the 
Makefiles myself and should have a gtk-free set of packages quite 
soon...

Anyone?

--

-- 
Nate Hill <vugdeox <at> freeshell.org>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Julio M. Merino Vidal | 1 Aug 2003 01:26

Re: Consistent "Optional Dependecy" handling

On Thu, 31 Jul 2003 18:18:54 -0500
Nate Hill <vugdeox <at> freeshell.org> wrote:

> > The OpenBSD "FLAVOR" like solution would be for the name of the
> > package to change too (i.e. add "-gtk" to the filename and maybe
> > also package name).
> 
> Yes, I also realized that this problem exits as we speak. Basically, 
> binary packages reflect the settings in defaults.mk. Of course, doing 
> something as big as isolating GTK1-v-GTK2 support will make this 
> problem obvious (NetBSD will have to decide which to use by default). 
> I think the FLAVOR solution sounds good...

Now suppose you have a package with the following conditionals (just
three!): arts, esound, gtk.  And you can do any combination of the three
when building a package.  So, if you want to keep users of binary packages
happy, you could end up with:

foobar-arts, foobar-esound, foobar-gtk, foobar-arts-esound, foobar-arts-gtk,
foobar-esound-gtk, foobar-arts-esound-gtk... *sigh*

This seems quite flexible, but I doubt it is really good.  And imagine what
could happen with... mplayer hehe.

Generalizing many variables will cause packages to slowly introduce this
"feature" and will extend the problem.  Keeping variables package specific
avoid this problem somewhat.  IMHO.

And, just curious.  What could happen if you have USE_GTK=NO and you try to
build, say xmms?  You get "pkg useless without gtk" or the package is built
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jeremy C. Reed | 1 Aug 2003 01:32

Re: Consistent "Optional Dependecy" handling

On Thu, 31 Jul 2003, Nate Hill wrote:

> > Many packages already do this :)
>
> Can you give me an example?

> I do not have the experience required to implement a USE_GTK
> infrastructure. However, if you can give me an example of conditions
> in Makefiles and, and some USE_* methods I am more than willing to
> convert some packages...

I assume you already have pkgsrc installed. Have a look at anyone of the
Makefiles (and maybe patches/) for the packages I referenced in my
earlier email.

For example, see chat/bitchx/Makefile.

In regards to the misc/kdepim3, you should try something there, like:

.if defined(KDEPIM_USE_PILOT) && !empty(KDEPIM_USE_PILOT:M[Yy][Ee][Ss])
.  include "../../comms/pilot-link-libs/buildlink2.mk"
.else
CONFIGURE_ARGS+=	--without-pilot
.endif

The above is just a guess. I don't know what it does to disable it. You
will have to read the docs or source for it.

   Jeremy C. Reed
   http://bsd.reedmedia.net/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeremy C. Reed | 1 Aug 2003 01:40

Re: Consistent "Optional Dependecy" handling

On Fri, 1 Aug 2003, Julio M. Merino Vidal wrote:

> foobar-arts, foobar-esound, foobar-gtk, foobar-arts-esound, foobar-arts-gtk,
> foobar-esound-gtk, foobar-arts-esound-gtk... *sigh*
>
> This seems quite flexible, but I doubt it is really good.  And imagine what
> could happen with... mplayer hehe.

That definitely wouldn't be useful for official downloads, but maybe for
some NetBSD users.

As for me, the only thing I really use is USE_PAM and USE_CRACKLIB under
Linux. (And on some custom pkgsrc of mine, I have a feature that makes it
so ncurses and other libraries are always registered as dependencies.) And
I don't want the package name (or filename) changed!

> And, just curious.  What could happen if you have USE_GTK=NO and you try to
> build, say xmms?  You get "pkg useless without gtk" or the package is built
> unconditionally as it's its default?

Just do its default -- and you get gtk.

   Jeremy C. Reed
   http://bsd.reedmedia.net/
Permalink | Reply | 0 comments |
headers
Juan RP | 1 Aug 2003 01:33

Re: Consistent "Optional Dependecy" handling

On Thu, Jul 31, 2003 at 06:32:55PM -0500, Nate Hill wrote:

> Okay, I see that there is already a USE_OSS flag (which is undefined 
> default) and it is checked in kdemultimedia3:
> 
> .if defined(USE_OSS)
> CONFIGURE_ARGS+=        --enable-audio=oss
> .endif
> 
> My question is wether I can implement this by just adding a USE_GTK 
> flag in bsd.pkg.defaults.mk? Is there some kludge that needs changing 
> elsewhere?

bsd.pkg.defaults.mk is only used to see what commons variables we can
use. You will have to do on any package that uses GTK, btw I don't like
this option, because we don't want many differents binaries packages, 
instead I prefer package-gtk or package-esd or whatever.

--

-- 
Juan RP		<jrp <at> hispabsd.org>
--
Permalink | Reply | 1 comment |
headers
Nate Hill | 1 Aug 2003 02:23
Picon
Favicon

Re: Consistent "Optional Dependecy" handling

On Thu July 31 2003 19:07, you wrote:
> On Thu, 31 Jul 2003, Nate Hill wrote:
> > +.if defined(USE_GTK)
>
> Also, you need to check for "yes" (because you want to have a "no"
> condition too).

Thanks.

> > Packages can be updated to use flags when found, or when someone
> > has time.
>
> It can be a lot more difficult than just a configure script.
> Sometimes patches need to be made and PLISTs changed.

Yes, I understand. Do you have commit access?

Besides my last rant on the binary "issue" I don't have much more to 
say. I'd like to start making some changes and sending them to 
someone experienced who can review/commit them. Anyone?

--

-- 
Nate Hill <vugdeox <at> freeshell.org>
Permalink | Reply | 1 comment |
headers
Juan RP | 1 Aug 2003 02:19

Re: Consistent "Optional Dependecy" handling

On Thu, 31 Jul 2003 19:23:27 -0500
Nate Hill <vugdeox <at> freeshell.org> wrote:

> Yes, I understand. Do you have commit access?
> 
> Besides my last rant on the binary "issue" I don't have much more to 
> say. I'd like to start making some changes and sending them to 
> someone experienced who can review/commit them. Anyone?

send-pr(1) is your friend, or you can send your patches to this 
mailing list if you want.

--

-- 
Juan RP		<jrp <at> hispabsd.org>
--
Permalink | Reply | 0 comments |
headers
Nate Hill | 1 Aug 2003 02:31
Picon
Favicon

Re: Consistent "Optional Dependecy" handling

Damnit! I can't seem to send mail... Here it is:
On Thu July 31 2003 18:33, Juan RP wrote:
> On Thu, Jul 31, 2003 at 06:32:55PM -0500, Nate Hill wrote:
> > Okay, I see that there is already a USE_OSS flag (which is
> > undefined default) and it is checked in kdemultimedia3:
> >
> > .if defined(USE_OSS)
> > CONFIGURE_ARGS+=        --enable-audio=oss
> > .endif
> >
> > My question is wether I can implement this by just adding a
> > USE_GTK flag in bsd.pkg.defaults.mk? Is there some kludge that
> > needs changing elsewhere?
>
> bsd.pkg.defaults.mk is only used to see what commons variables we
> can use. You will have to do on any package that uses GTK, btw I
> don't like this option, because we don't want many differents
> binaries packages, instead I prefer package-gtk or package-esd or
> whatever.

It has come to my attention that this binary package "issue" is going 
to become a rather large one. So, I'd like to address it before 
another flamewar begins.

-This problem already exists.
 There are many trivial USE-like flags in the various .mk files which 
change aspects of a package. The binary packages released by NetBSD 
are all built with the default settings. Major features (I can really 
only think of the gtk one atm) are handled with alternate package 
names, like: foo-gtk1 and foo-gtk2. If you want to build a foo
(Continue reading)

Permalink | Reply | 0 comments |

Gmane