Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 29 Dec 2001 12:01:06 -0500
From:      Pete Fritchman <petef@databits.net>
To:        Mikhail Teterin <mi@aldan.algebra.com>
Cc:        ports@FreeBSD.ORG
Subject:   Multiple packages from one port
Message-ID:  <20011229120106.B53652@databits.net>
In-Reply-To: <200112291644.fBTGi3f50093@aldan.algebra.com>; from mi@aldan.algebra.com on Sat, Dec 29, 2001 at 11:44:00AM -0500
References:  <00b701c19036$21e6eba0$11fd2fd8@westbend.net> <200112291644.fBTGi3f50093@aldan.algebra.com>

next in thread | previous in thread | raw e-mail | index | archive | help
[ cc: trimmed]

++ 29/12/01 11:44 -0500 - Mikhail Teterin:
| Makes sense.  If only we weren't  so fixated on the  pre-built packages,
| there'd be nothing to talk about.

Ports are about building packages.  I would guess that a majority of our
users tend to use packages (we just hear about the people using ports
more because they are the ones emailing bug reports to ports@ or the
respective maintainer).  I've introduced about 10 of my friends to
FreeBSD in the past few months, all of them being fairly unix
illiterate.  They all *love* packages.  I can't get them to touch ports
-- they think it's too complicated.  I think we need to focus on making
the best quality packages available that we can.

| > The  frontpage-<lang> ports  are not  slave ports  of frontpage  port.
| > They  are  slave   ports  to  the  first  FrontPage   Web  Admin  port
| > (www/frontpage-ar).
| 
| Ok, thanks.  Pardon my ignorance.  What I really  meant to say,  is they
| should all  be made into one  port -- with options,  just like kde2-i18n
| (or php, or ghostscript).  Unless, of course, we are in a  race to hit a
| certain port-number growth target :-)

I agree with you -- they *should*.  This would be ideal.

| > As the maintainer, I  feel that this is currently the  only way to get
| > packages built for each of the FrontPage Web Admin pages ports.
| 
| And to me this "only way" is  not an acceptable one either :-) That's my
| only point from the beginning of this tiring thread...
|  
| > Something like:
| >      @comment PORT_BUILD_OPTION=%%PORT_OPTIONS%%
| 
| No, a whole "language" will need to be devised -- using make's variables
| to describe which options exist, and whether they are mutually exclusive
| (radio buttons)  or lists or  on/off, etc... During  interactive builds,
| the bsd.ports.mk will also be able to use this to inform the user of the
| possible  options  (some  ports  do  it themselves  now).
| 
| But this is off-topic -- it is up  to the "Bento team" to devise the new
| scheme -- the existing "one package per port" one is insufficient.

Err, there really isn't a "bento team".  You realize that bento is just
a "cvs co" of ports, which the "Ports team" is responsible for.  (Yes
yes I know there is now a 4-exp build, but things in 4-exp are
soon-to-be in ports repo if things go right).  If something is to be
done with making multiple packages from one port, then the general
porting team is going to have to work together on it.

It would probably be a useful exercise to study the OpenBSD system of
flavors, and I'm not too familiar with NetBSD pkgsrc but see if they
have something similiar.  Flavors don't exactly provide all the fine
tuning we seem to desire (say if options "a b c" exist, there wouldn't
be an automatic build with options "a b").  It's going to be hard to
automate this, and come up with a way of representing all the options
available in a port and which other options they work/don't work with...
it's not going to happen overnight.

Instead of fighting over frontpage ports, let's brainstorm and try to
come up with something useful to build multiple packages from one port
-- this would be a great feature.

-pete

--
Pete Fritchman [petef@(databits.net|freebsd.org|csh.rit.edu)]
finger petef@databits.net for PGP key

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011229120106.B53652>