Date: Sun, 7 Feb 1999 14:59:34 +1030 (CST) From: Kris Kennaway <kkennawa@physics.adelaide.edu.au> To: Randall Hopper <aa8vb@pagesz.net> Cc: ports@FreeBSD.ORG Subject: Re: ANN: Fxtv 0.48 Message-ID: <Pine.OSF.4.05.9902071437330.18799-100000@bragg> In-Reply-To: <19990206225747.A5522@pagesz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 6 Feb 1999, Randall Hopper wrote: > Kris Kennaway: > |On Sat, 6 Feb 1999, Randall Hopper wrote: > |So, you don't need libjpeg here. > > Thanks. I'd gotten another reply to that effect as well, so for this > specific case, sounds like nuking jpeg is the easiest way to stay > compatible with the current branch releases (2.2.8, 3.0) and 4.0-current. There's only one ports tree. If people want to use a port which isn't part of their release snapshot, they're expected to update the ports tree. If people insist on running a partly-old version of their ports tree, they're likely to run into problems and the answer when they come for support is likely to be "cvsup your ports tree". > |When your port update gets committed, how are people going to have access > |to it unless they update their ports collection (cvsup, whatever)? If > |they update their ports collection, they at the same time get the current > |port framework for libjpeg, and everything else. If they try and only > |update one collection (e.g. ports-graphics) then in this case it will > |still work, since fxtv and jpeg are both in graphics. In general however, > |people are expected to upgrade the whole lot at once if they want to > |upgrade at all, otherwise things will not work. > > Update the entire ports collection whenever you want the > latest-and-greatest of one utility? Does that mean removing existing My understanding is that it's the only "supported" way to do it. Sure, you can do it manually by fetching only the latest versions of the port, plus all of its dependency tree, but this is likely to fail if you're not sure of what you're doing, or miss one of the dependencies. > packages, fetching the new ports and any updated src packages, and > rebuilding the port world). That's pretty extreme (and not practical for > most folks). No, just the ports framework (not the distfiles, except of course for the ones you need). Using cvsup is the easiest way do this by far. I cvsup over my 14.4k modem from Australia and it takes 5 minutes at the most, if I havent dont it for a week or two. Once you have the latest port tree, whether or not you upgrade existing packages to newer versions is optional (see sysutils/pkg_version however). It does ensure that if you try and compile something which depends on a newer version of a library, or an entire port which didn't exist in your older snapshot, then it will work (upgraded versions of non-libraries - e.g. binaries, are often harder to notice and have to be upgraded by hand if it's a hard dependency, e.g. the port needs some new feature not present in your older version) Using cvsup is really trivial, takes 5 minutes to set up and runs using a single command. If you pick a mirror site which is topologically close to you then it will be reasonably fast even with poor connectivity. > For that reason, I'd like the port to support the latest -RELEASEs (2.2.8, > 3.0). Development branch support (-stables and -current) is a plus of > course so the port can be checked in, updated as the port world evolves, > and bundled with the next target -RELEASE. I don't know of any other ports which try and stay backwards-compatible with older snapshots of the ports tree like you suggested. It's generally accepted that if you want to use a new port, you have to upgrade the other things it depends on to the latest versions also (either by hand, which is difficult and error-prone, or by using cvsup to do it automatically). > |In other words, build your ports against the 'head' of the ports collection > |(where things are now) - it's the only supported ports collection for all > |FreeBSD releases. > > I'm confused as to what you mean by "head". Do you mean, -stable? For > example, 3.0-stable is the only supported ports/package collection for > 3.0-RELEASE? I think have must have misunderstood. There is only one ports cvs collection. When x.y-release comes along, a 'snapshot' is taken of the current contents of the cvs tree, and that becomes the contents of /usr/ports in the x.y-release CD. The day after the snapshot is taken, the ports cvs tree moves on. These are all snapshots of a single moving target - there's no "3.0-release ports branch" which is maintained separately to the "2.x ports branch", the "4.x ports branch", etc. > If I didn't, it seems to me that folks buying/running a FreeBSD -RELEASE > ought to be able to install it and go fetch latest-and-greatest > software/utils off the web that they can build for -RELEASE and register > with the FreeBSD package manager without having to try to sup part/all of > -stable. -stable and -current are development branches afterall. The > average user probably runs -RELEASE. They can. The latest/greatest ports collection is a separate CVS tree to the -stable/-current source trees. Please read the relevant sections in the handbook - this is pretty basic stuff about how the project is organised. Kris > > Thanks, > > Randall > ----- (ASP) Microsoft Corporation (MSFT) announced today that the release of its productivity suite, Office 2000, will be delayed until the first quarter of 1901. 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?Pine.OSF.4.05.9902071437330.18799-100000>