Date: Sat, 9 Sep 2000 02:07:03 +0200 From: Neil Blakey-Milner <nbm@mithrandr.moria.org> To: Satoshi - Ports Wraith - Asami <asami@FreeBSD.org> Cc: Will Andrews <will@physics.purdue.edu>, FreeBSD Ports <ports@FreeBSD.org> Subject: Re: Ports Options Paper Message-ID: <20000909020702.A64259@mithrandr.moria.org> In-Reply-To: <200009082243.e88Mh9V05579@silvia.hip.berkeley.edu>; from asami@FreeBSD.org on Fri, Sep 08, 2000 at 03:43:09PM -0700 References: <20000903052226.E1205@radon.gryphonsoft.com> <200009082243.e88Mh9V05579@silvia.hip.berkeley.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri 2000-09-08 (15:43), Satoshi - Ports Wraith - Asami wrote:
> (1) The support infrastructure for something like you propose is not
> there yet. For one thing, we need to move from ${PKG_DBDIR}/${PKGNAME}
> to ${PKG_DBDIR}/${PORTNAME}/ver${PORTVERSION} (or some such)
That doesn't make a difference at all (unless I'm missing something).
${PORTNAME}-${PORTVERSION} gives the same information as
${PORTNAME}/${PORTVERSION}. I've seen this suggested many times, and
every time I say this, and then noone sends me a reply. I'm not against
the change, but I don't see what it gives us.
I'd much rather see some sort of commitment to support multiple versions
of software that have to co-exist. Debian uses ssh-1.2.13 and
ssh2-2.1.0, libqt1-1.45 and libqt2-2.0.2, and similar package
identities, and concepts like "upgrades", "conflicts", and such.
We need a subtle context of "streams" of programs so we know that
qt-1.45 and qt-2.0.2 can co-exist, and that qt-1.44 upgrades to qt-1.45
and not qt-2.0.2, &c. I'd suggest a (hopefully the final?) "stream"
number in the version number, if we're not willing to muddy the package
name with it. (I'm not too taken with muddying the package names, truth
be told)
> (2) Speaking of updates, we first need to implement updates. There
> are lots of sticky problems, such as what to do when a port in the
> middle of the dependency chain is updated (do we update all ports
> that depend on this one as well as all ports that this ports
> depend on?), etc.
To implement updates, we need (roughly, I think I've forgotten one):
(forgive me if this sounds familiar, I've sent this two or three times
before)
1) relative dependencies
This is so we don't have to have a _perfectly_ up to date package system
constantly. Who cares if we have bash 2.1.3 or bash 2.1.4, unless we
know there's a problem in bash 2.1.3? (for packages, mostly, but I
wouldn't mind seeing it in ports too.)
2) virtual packages (for ports and packages)
We don't really care if we have apache-1.3.12 or
apache-modssl-1.3.12+1.0.3, so long as we have apache. apache ports can
export virtual package 'virtapache-1.3.12', and something simple like
'static-webserver-1.0.0' and 'cgi-webserver-1.0.2'.
Does it really matter if we have nawk or gawk or one-true-awk, so long
as one responds as 'awk' and is awk-compatible.
Also, some applications may be affected by a library bug, and others may
not - so while gview needs gtk-1.2.5 with libgtk12.so.3, gftp will still
work fine when you upgrade from it's initial gtk-1.2.3 to gtk-1.2.5,
since it uses standard libgtk12.so.3 functions, and doesn't need
recompiling.
3) port-epoch and port-revision (which we should have soon, after kkenn
took my cause over.) (for ports and packages)
These are necessary for external views of internal version numbers. I
prefer externalising them, since I think people who take the time to
understand them can gain a huge deal from a quick glance. It also helps
making decisions on whether we're up-to-date reasonably easy.
It will let us determine almost mostly from the filename whether we need
look into upgrading. (not that I'd rely on this, but rather the next:)
4) synchronized INDEXs from (possibly) multiple sources (for packages)
This is necessary mostly for people who subsist on packages. We must
know that if we upgrade to sawfish-0.38, we must upgrade to rep-gtk-1.3,
&c. We also need to know if something that relies on rep-gtk-1.2 will
need to be upgraded if rep-gtk-1.3 is installed. (This is hard, and is
why virtual packages denoting shared libraries may be necessary.)
Then we have to do it all backwards if they try use a CDROM, and then
forwards again if they move to a closer mirror that is slightly out of
date, &c.
5) a concept of streams (very limited number, but incredibly useful)
Explained above.
Not totally related, but we may need to explore NetBSD(?)'s piecemeal
packages (build port once, make multiple packages from the collected
bits). Debian does something like this, and provides libgtk12 with just
the shared library and run-time stuff, and libgtk12-dev, with the static
library and include files and developer stuff.
> Next, specific comments.
>
> * The reasons for putting such things in a separate file is to
> * simplify parsing for GUI-style programs like gportconf (which
> * nbm proposed using with his XML format) or dialog(1), which
> * would be the default user-friendly interface. It would also
> * reduce clutter in port Makefiles somewhat.
>
> That is a good idea.
I wouldn't have minded this feedback 18 months ago when I suggested and
implemented it and got no response whatsoever.
Using only base system tools, with examples, and an overview. And with
example gtk programs that used a shared library that sysinstall could
use too.
With multiple reminders of what I was doing over a few months period.
Actually, the only feeback I got (at the time, before Will started
talking to me about it) was from old guru sysadmin types who didn't
understand what we'd possibly need any of this fancy stuff when you can
just look in the Makefile and figure it out.
> * The *_DEPENDS can also be moved to ${FILESDIR}/options:
> *
> * LIB_DEPENDS= kdecore.4:${PORTSDIR}/x11/kdelibs2
> * RUN_DEPENDS= konqueror:${PORTSDIR}/x11/kdebase2 \
> * kjumpingcube:${PORTSDIR}/games/kdegames2 \
> * kdf:${PORTSDIR}/misc/kdeutils2 \
> * kword:${PORTSDIR}/editors/koffice \
> * kppp:${PORTSDIR}/net/kdenetwork2
>
> I'm not sure about this. I'd like to keep enough information in the
> Makefile so people working on ports don't have to check many files to
> figure out just what the port does.
I agree, but porters are going to have to get used to looking for
options files. But we should probably write tools that will remind them
and ease it for them.
(By the way, do we have any cases where we don't have
_${PORTSDIR}_/x11/kdelibs? It seems a bit redundant if it isn't used.
> * Another issue that I've stumbled across over time has been the inability
> * of a single port to create multiple packages. Hence, I'd like to reintroduce
>
> This is not a good idea. We've tried it before, and it was a
> disaster. The current MASTERDIR has come out of the smoldering ashes
> of failed attempts to create a framework to build multiple packages
> from the same directory.
>
> "One package per port" is the First Principle of the Ports Collection
> for a good reason. :)
I warned Will that this would be the answer *grin*. I remember I got
this answer too when I asked it 18 or so months ago.
I dislike the idea of extra directories simply to hold a Makefile that
sets one or two variables, but if we must do it this way, we should use
your multi-level ports magick to "hide" it from the users:
mail/mutt
mail/mutt/ssl
lang/python-doc/html
lang/python-doc/pdf-a4
lang/python-doc/pdf-letter
lang/python-doc/postscript-a4
lang/python-doc/postscript-letter
It's an equal waste of inodes, but at least it doesn't crowd things.
Of course, given sufficient effort by people on the libh project, we
could use the system that has been designed there (which, from what I've
seen, handles everything I've listed above). The code is a bit hard to
understand at times, but reading the sysinstall2.txt file a few times
gives you an idea on why it is done the way it is. People can sign-up
by subscribing to, and posting a "how can I help?" message to
freebsd-libh@FreeBSD.org.
Beware, tcl and C++ dragons abound.
Neil
--
Neil Blakey-Milner
Sunesi Clinical Systems
nbm@mithrandr.moria.org
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?20000909020702.A64259>