public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Dan Armak <danarmak@gentoo.org>
To: gentoo-dev@cvs.gentoo.org
Subject: Re: [gentoo-dev] Checking availability of a package from an ebuil d
Date: Wed Jul 18 10:48:02 2001	[thread overview]
Message-ID: <01071819482906.00590@localhost> (raw)
In-Reply-To: <1DCB85BD45DED211B12D009027279E4F4767C9@murcury>

On Wednesday 18 July 2001 17:47, you wrote:
> > No I mean when _writing_ an ebuild, I want it to do different
> > things based on
> > whether some packages are installed.
>
> But should you? I guess it really depends on the specifics of what you are
> doing, but as a general statement I think that an ebuild shouldn't make a
> decision on how to build a package based on the fact that I currently have
> something installed. I think the USE variables (plus the system you
> proposed earlier) are the Way.
>
> Let's say I install vorbis (to continue our earlier discussion) to play
> around with for a while but I don't set the USE for it. I decide I don't
> like it and unmerge it. In the meantime I've merged a bunch of audio
> utilities that have decided to build in vorbis support and now get snivelly
> because it's not there anymore.
>
> This may not be in the least applicable to the situation you are working
> on, but I think it merits a mention....
>

I agree. If what I suggested (i.e. interactive decisions) is implemented, 
there'll be no problems. On the other hand, while we continue to use USE 
flags, such decisions may need to be made. But what I had in mind really was 
an unusual case.

-- 

Dan Armak
Gentoo Linux Developer
Matan, Israel



  reply	other threads:[~2001-07-18 16:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-18  8:50 [gentoo-dev] Checking availability of a package from an ebuil d Sean Mitchell
2001-07-18 10:48 ` Dan Armak [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-07-18  7:00 Sean Mitchell
2001-07-18  8:34 ` Dan Armak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=01071819482906.00590@localhost \
    --to=danarmak@gentoo.org \
    --cc=gentoo-dev@cvs.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox