|
|
|
|
|
|
| Author |
Message |
Rahul Siddharthan
*nix forums beginner
Joined: 09 Jul 2002
Posts: 11
|
 Posted: Sat Jul 13, 2002 12:18 pm Post subject:
Re: Other BSD's (was Re: Cleaning old packages (was: Package system flaws?))
|
|
|
Nik Clayton said on Jul 12, 2002 at 21:22:31:
| Quote: | 3. You can fetch all the source tarballs (including dependencies, but
excluding what's already installed) in one shot, before building
anything.
make fetch-recursive
|
Deja vu on -chat... The key phrase in what I wrote was "excluding
what's already installed." fetch-recursive fetches everything which
is a waste of time and bandwidth. But as DES pointed out, porteasy
can do what I wanted (though it still prints the results in
alphabetical order, I prefer Gentoo's output which is in order of what
will be installed).
- Rahul
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
 |
Nik Clayton
*nix forums beginner
Joined: 09 Apr 2002
Posts: 20
|
| Posted: Fri Jul 12, 2002 6:22 pm Post subject:
Re: Other BSD's (was Re: Cleaning old packages (was: Package system flaws?))
|
|
|
On Thu, Jul 11, 2002 at 09:31:05AM +0200, Rahul Siddharthan wrote:
| Quote: | 3. You can fetch all the source tarballs (including dependencies, but
excluding what's already installed) in one shot, before building
anything.
|
make fetch-recursive
Yes, this stuff needs to be better documented.
N
--
FreeBSD: The Power to Serve http://www.freebsd.org/ (__)
FreeBSD Documentation Project http://www.freebsd.org/docproj/ \\\'',)
\/ \ ^
--- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- .\._/_) |
|
| Back to top |
|
|
Cyrille Lefevre
*nix forums beginner
Joined: 12 Jun 2002
Posts: 48
|
| Posted: Thu Jul 11, 2002 4:29 pm Post subject:
Re: Other BSD's (was Re: Cleaning old packages (was: Package system flaws?))
|
|
|
On Thu, Jul 11, 2002 at 09:31:05AM +0200, Rahul Siddharthan wrote:
[snip]
| Quote: | Hm, then, why not steal those ideas? It shouldn't be too hard and
|
don't know, try to search the -arch ml ?
| Quote: | would solve a few problems.
Some other things I like about gentoo are
2. you can do a "pretend" install, which will tell you which
dependencies and version numbers would be installed (ignoring
the ones which are already installed on your system), but not do
anything.
|
pkg_add -n ? (not tested)
| Quote: | On that topic, with all the talk of ambitious new ports systems, does
it make sense to go the route of, eg, openpackages
(http://www.openpackages.org)? Perhaps they've already thought about
many of these issues, and if one wants cross-architecture across
FreeBSD, maybe it makes sense to go cross-BSD as well. The project
seems to be dead or asleep (last webpage update 31 July 2001).
|
as well as the ml which sleep since may 2002.
Cyrille.
--
Cyrille Lefevre mailto:cyrille.lefevre@laposte.net
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Dag-Erling Smorgrav
*nix forums Guru Wannabe
Joined: 23 Mar 2002
Posts: 110
|
| Posted: Thu Jul 11, 2002 6:34 am Post subject:
Re: Other BSD's (was Re: Cleaning old packages (was: Package system flaws?))
|
|
|
Rahul Siddharthan <rsidd@online.fr> writes:
| Quote: | 2. you can do a "pretend" install, which will tell you which
dependencies and version numbers would be installed (ignoring
the ones which are already installed on your system), but not do
anything.
|
# porteasy -le <port-name>
| Quote: |
3. You can fetch all the source tarballs (including dependencies, but
excluding what's already installed) in one shot, before building
anything.
|
# porteasy -f <port-name>
DES
--
Dag-Erling Smorgrav - des@ofug.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Rahul Siddharthan
*nix forums beginner
Joined: 09 Jul 2002
Posts: 11
|
| Posted: Thu Jul 11, 2002 5:31 am Post subject:
Other BSD's (was Re: Cleaning old packages (was: Package system flaws?))
|
|
|
Cyrille Lefevre said on Jul 11, 2002 at 02:52:47:
| Quote: | That seems rather ambitious, and too drastic a change, to me. What
I'd like to see is probably more like, the gfoo port needs gtk+ 1.2.6
or above, but not gtk+ 2.0 and above (incompatible) and not gtk+ 1.2.5
or below (buggy). There should be some way to specify this in the
makefile of the port, so that any port-management program like
portupgrade can make use of the information.
take a look at NetBSD pkg (aka ports) system, they have this kind
of version handling.
(3) Automatically generate the +CONTENTS file by first doing a "fake"
install in a temporary directory (assuming the port honours
$PREFIX), then moving the contents to their final destination (a la
gentoo). If your temporary location is on the same filesystem as
the final one, it won't even take additional disk space, and very
little additional time. Is there any obvious drawback with doing
this?
that's what OpenBSD port system has...
|
Hm, then, why not steal those ideas? It shouldn't be too hard and
would solve a few problems.
Some other things I like about gentoo are
1. it supports multiple versions of the same port in the tree, and in
the case of the latest-and-greatest versions which have potential
problems, installing it can be "blocked" by the maintainer in a
package.mask file, but it's still available for those who want to try
it (they have to edit package.mask first).
2. you can do a "pretend" install, which will tell you which
dependencies and version numbers would be installed (ignoring
the ones which are already installed on your system), but not do
anything.
3. You can fetch all the source tarballs (including dependencies, but
excluding what's already installed) in one shot, before building
anything.
Are there such features in the other BSDs? In principle I think
(1) could be done with differently named makefiles for different
versions, and (2) could be implemented within the existing ports system.
DES pointed out that (3) can be done by his porteasy.
On that topic, with all the talk of ambitious new ports systems, does
it make sense to go the route of, eg, openpackages
(http://www.openpackages.org)? Perhaps they've already thought about
many of these issues, and if one wants cross-architecture across
FreeBSD, maybe it makes sense to go cross-BSD as well. The project
seems to be dead or asleep (last webpage update 31 July 2001).
- Rahul
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Cyrille Lefevre
*nix forums beginner
Joined: 12 Jun 2002
Posts: 48
|
| Posted: Wed Jul 10, 2002 10:52 pm Post subject:
Re: Cleaning old packages (was: Package system flaws?)
|
|
|
message resent due to mta misconfigation.
On Wed, Jul 10, 2002 at 01:18:20AM +0200, Cyrille Lefevre wrote:
| Quote: | On Tue, Jul 09, 2002 at 07:14:17PM +0200, Rahul Siddharthan wrote:
[snip]
That seems rather ambitious, and too drastic a change, to me. What
I'd like to see is probably more like, the gfoo port needs gtk+ 1.2.6
or above, but not gtk+ 2.0 and above (incompatible) and not gtk+ 1.2.5
or below (buggy). There should be some way to specify this in the
makefile of the port, so that any port-management program like
portupgrade can make use of the information.
take a look at NetBSD pkg (aka ports) system, they have this kind
of version handling.
(3) Automatically generate the +CONTENTS file by first doing a "fake"
install in a temporary directory (assuming the port honours
$PREFIX), then moving the contents to their final destination (a la
gentoo). If your temporary location is on the same filesystem as
the final one, it won't even take additional disk space, and very
little additional time. Is there any obvious drawback with doing
this?
that's what OpenBSD port system has...
|
Cyrille.
--
Cyrille Lefevre mailto:cyrille.lefevre@laposte.net
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
| Posted: Tue Jul 09, 2002 9:27 pm Post subject:
Re: Cleaning old packages (was: Package system flaws?)
|
|
|
Rahul Siddharthan wrote:
| Quote: | So I think both the port, and the dependency, should carry some sort
of versioning information. The port should say which versions of the
dependency it's compatible with, and the dependency should say which
earlier versions are safe to upgrade from.
|
We used to put these things called "minor version numbers" on
shared libraries, back in the pre-ELF days.
They were removed when ELF came in. The reason given was $REASON
....oops... sorry... looks like that variable still doesn't expand.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Rahul Siddharthan
*nix forums beginner
Joined: 09 Jul 2002
Posts: 11
|
| Posted: Tue Jul 09, 2002 7:09 pm Post subject:
Re: Cleaning old packages (was: Package system flaws?)
|
|
|
Simon Marlow said on Jul 9, 2002 at 21:10:07:
| Quote: | Rahul Siddharthan <rsidd@online.fr> writes:
That seems rather ambitious, and too drastic a change, to me. What
I'd like to see is probably more like, the gfoo port needs gtk+ 1.2.6
or above, but not gtk+ 2.0 and above (incompatible) and not gtk+ 1.2.5
or below (buggy). There should be some way to specify this in the
makefile of the port, so that any port-management program like
portupgrade can make use of the information.
A port can't know which versions of a library it will be compatible
with ahead of time. Only the port itself knows which older versions
of itself are compatible with the current version, so the information
about whether an upgrade is safe or not should reside in the port
which is being upgraded.
|
OK, these are two different problems I think. My problem is, is it
*necessary* to upgrade the gtk+ port (from the point of view of gfoo);
and your problem is, is it *safe* to do so. In principle, any of the
four possibilities could exist; to take libpng as an example:
neither safe nor necessary (this was true of a very large number of
ports which depended on libpng, during the 1.0 -> 1.2 transition)
safe but not necessary (usually, upgrading through minor versions,
like libpng 1.2.2 -> 1.2.3)
necessary but not safe (a port which depends on libpng 1.2.x and won't
work with libpng 1.0.x)
both safe and necessary (a bugfix in the earlier version which doesn't
affect compatibility otherwise)
So I think both the port, and the dependency, should carry some sort
of versioning information. The port should say which versions of the
dependency it's compatible with, and the dependency should say which
earlier versions are safe to upgrade from.
- Rahul
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Simon Marlow
*nix forums beginner
Joined: 09 Jul 2002
Posts: 1
|
| Posted: Tue Jul 09, 2002 6:10 pm Post subject:
Re: Cleaning old packages (was: Package system flaws?)
|
|
|
Rahul Siddharthan <rsidd@online.fr> writes:
| Quote: | That seems rather ambitious, and too drastic a change, to me. What
I'd like to see is probably more like, the gfoo port needs gtk+ 1.2.6
or above, but not gtk+ 2.0 and above (incompatible) and not gtk+ 1.2.5
or below (buggy). There should be some way to specify this in the
makefile of the port, so that any port-management program like
portupgrade can make use of the information.
|
A port can't know which versions of a library it will be compatible
with ahead of time. Only the port itself knows which older versions
of itself are compatible with the current version, so the information
about whether an upgrade is safe or not should reside in the port
which is being upgraded. This why the suggestion of using capability
names or APIs to specify the functionality is a better way, but I
think it's perhaps a level of abstraction too far.
I've always been annoyed by the way the ports system spams older
versions of ports with newer ones. It isn't safe to do in general, so
IMO the ports system should at the least just refuse to continue if it
finds it needs to do this. Then if the specification for a port had
some way to say that it was safe to upgrade certain versions to the
new version, it could go ahead (deleting the old one first, of
course).
So here's my suggestions:
- Allow a port to specify a range of versions which are safe
to upgrade to the current version without user intervention.
- The ports system should *not* automatically install a new version
of a port over an old one. If the port says it is safe to do so,
then remove the old port and install the new one.
Allowing dependencies to specify version ranges would help reduce the
number of upgrades required, but wouldn't otherwise improve matters.
Also it requires updates to N ports rather than 1 for each dependency,
so is far more error prone.
(disclaimer: I'm lazy and haven't looked at libh, so I apologise if
this is old news)
Cheers,
Simon
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
John Baldwin
*nix forums Guru Wannabe
Joined: 27 Mar 2002
Posts: 278
|
| Posted: Tue Jul 09, 2002 4:47 pm Post subject:
Re: Cleaning old packages (was: Package system flaws?)
|
|
|
On 09-Jul-2002 Rahul Siddharthan wrote:
| Quote: | Dan Nelson said on Jul 9, 2002 at 10:49:13:
new package. Suppose you had installed foo-1.3.1, and then another
port you were installing overwrote this with foo-1.3.2. Now both are
registered in /var/db/pkg but you can't pkg_delete foo-1.3.1 because
it will remove files with common names from foo-1.3.2.
If you use portupgrade to install ports and packages, it will deinstall
the old port before installing the new one.
Since you're the third person telling me this (the first two were
off-list) let me clarify -- I know about portupgrade. Yes, if I use
only portupgrade and nothing else, I won't have the problem. But
using portupgrade all the time is totally unrealistic: (1) it has
problems with binary packages, and (2) I don't like rebuilding every
dependency which has had the most minor of changes every time I
install a new port. Besides, portupgrade is not part of the base
system, it's an add-on, so in my opinion saying "use portupgrade" is
not an answer. If you use the base system tools you *will* run into
the problem of duplicate installed packages, rather quickly.
I was initially impressed with portupgrade, but after using it a while
I realized it solves problems which I don't have and not the ones I
have. Mainly, I want dependency tracking (which the ports system
supplies already) but I don't want to upgrade old packages
automatically unless it's essential or I specifically ask for it. As
others have pointed out, what's needed is using version ranges to
express dependencies.
|
Or rather, to depend on abstract functions provided by other packages.
I.e., package A might depend on the 'foo' functionality which is provided
by package B. Thus, package A is not tied to B's specific version. If
you have a new API then you can append a version to 'foo'. For example,
you might have 'qt1', 'qt2', 'gtk12', etc. "functions". RPM does this
and I think that the new /etc/rc.d stuff in current uses a similar scheme.
RPM also supports the notion of a package having a function that conflicts
with other functions.
The idea though is that dependencies aren't strictly on a package, but on
functoinality provided by that package. This does mean more work when
trying to figure out how to fulfill a needed dependency, however.
--
John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Rahul Siddharthan
*nix forums beginner
Joined: 09 Jul 2002
Posts: 11
|
| Posted: Tue Jul 09, 2002 3:14 pm Post subject:
Re: Cleaning old packages (was: Package system flaws?)
|
|
|
John Baldwin said on Jul 9, 2002 at 12:47:17:
| Quote: |
Or rather, to depend on abstract functions provided by other packages.
I.e., package A might depend on the 'foo' functionality which is provided
by package B. Thus, package A is not tied to B's specific version. If
you have a new API then you can append a version to 'foo'. For example,
you might have 'qt1', 'qt2', 'gtk12', etc. "functions". RPM does this
and I think that the new /etc/rc.d stuff in current uses a similar scheme.
RPM also supports the notion of a package having a function that conflicts
with other functions.
|
That seems rather ambitious, and too drastic a change, to me. What
I'd like to see is probably more like, the gfoo port needs gtk+ 1.2.6
or above, but not gtk+ 2.0 and above (incompatible) and not gtk+ 1.2.5
or below (buggy). There should be some way to specify this in the
makefile of the port, so that any port-management program like
portupgrade can make use of the information.
Right now, dependencies are typically specified by files (binaries or
shared libraries) which are searched for before proceeding. This is
better than a "hard" version number requirement and works a lot of the
time, but not always.
I'll have a stab at writing something in some scripting language. I'm
planning to try and implement some of the following features, for a
start, which I think can be done without any modification to the
existing ports tree/system:
(1) Upgrade dependencies only if essential, and then too only after user
confirmation, perhaps listing the possible affected packages (to
avoid things like the libpng chaos some time ago). Perhaps allow
"pinning" to a certain version number, so that it will never be
upgraded unless you manually "un-pin" it.
(2) When upgrading dependencies, provide a way to safely remove old
versions of duplicate packages, as I described in my earlier mail.
(3) Automatically generate the +CONTENTS file by first doing a "fake"
install in a temporary directory (assuming the port honours
$PREFIX), then moving the contents to their final destination (a la
gentoo). If your temporary location is on the same filesystem as
the final one, it won't even take additional disk space, and very
little additional time. Is there any obvious drawback with doing
this?
If anyone is interested, the gentoo portage system is described here:
http://www.gentoo.org/doc/portage-manual.html
- Rahul
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Rahul Siddharthan
*nix forums beginner
Joined: 09 Jul 2002
Posts: 11
|
| Posted: Tue Jul 09, 2002 2:19 pm Post subject:
Re: Cleaning old packages (was: Package system flaws?)
|
|
|
Dan Nelson said on Jul 9, 2002 at 10:49:13:
| Quote: | new package. Suppose you had installed foo-1.3.1, and then another
port you were installing overwrote this with foo-1.3.2. Now both are
registered in /var/db/pkg but you can't pkg_delete foo-1.3.1 because
it will remove files with common names from foo-1.3.2.
If you use portupgrade to install ports and packages, it will deinstall
the old port before installing the new one.
|
Since you're the third person telling me this (the first two were
off-list) let me clarify -- I know about portupgrade. Yes, if I use
only portupgrade and nothing else, I won't have the problem. But
using portupgrade all the time is totally unrealistic: (1) it has
problems with binary packages, and (2) I don't like rebuilding every
dependency which has had the most minor of changes every time I
install a new port. Besides, portupgrade is not part of the base
system, it's an add-on, so in my opinion saying "use portupgrade" is
not an answer. If you use the base system tools you *will* run into
the problem of duplicate installed packages, rather quickly.
I was initially impressed with portupgrade, but after using it a while
I realized it solves problems which I don't have and not the ones I
have. Mainly, I want dependency tracking (which the ports system
supplies already) but I don't want to upgrade old packages
automatically unless it's essential or I specifically ask for it. As
others have pointed out, what's needed is using version ranges to
express dependencies.
Portupgrade (pkgdb -F) also has a "fix" for duplicate packages but it
doesn't actually remove any redundant files -- it tacks all the
+CONTENTS to the most recently installed package and removes the
entries of the rest. I think one can do better.
Gentoo Linux's (http://www.gentoo.org) "portage" system has a lot of
nice ideas worth stealing, in my opinion (in particular it supports
version ranges, but other things too). At some point during the next
month I was thinking of implementing some gentoo-like features on
freebsd for my own use (but since I'm not an expert C programmer I'll
probably end up using python or something like that.)
- Rahul
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Dan Nelson
*nix forums Guru Wannabe
Joined: 09 Jul 2002
Posts: 135
|
| Posted: Tue Jul 09, 2002 1:49 pm Post subject:
Re: Cleaning old packages (was: Package system flaws?)
|
|
|
In the last episode (Jul 09), Rahul Siddharthan said:
| Quote: | I'm not subscribed to this list but I happened on this discussion in
the archives today.
One mild peeve I've had about FreeBSD's ports system is the
difficulty of deleting an old package which has been overwritten by a
new package. Suppose you had installed foo-1.3.1, and then another
port you were installing overwrote this with foo-1.3.2. Now both are
registered in /var/db/pkg but you can't pkg_delete foo-1.3.1 because
it will remove files with common names from foo-1.3.2.
|
If you use portupgrade to install ports and packages, it will deinstall
the old port before installing the new one.
--
Dan Nelson
dnelson@allantgroup.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Rahul Siddharthan
*nix forums beginner
Joined: 09 Jul 2002
Posts: 11
|
| Posted: Tue Jul 09, 2002 9:35 am Post subject:
Cleaning old packages (was: Package system flaws?)
|
|
|
I'm not subscribed to this list but I happened on this discussion in
the archives today.
One mild peeve I've had about FreeBSD's ports system is the difficulty
of deleting an old package which has been overwritten by a new
package. Suppose you had installed foo-1.3.1, and then another port
you were installing overwrote this with foo-1.3.2. Now both are
registered in /var/db/pkg but you can't pkg_delete foo-1.3.1 because
it will remove files with common names from foo-1.3.2.
I've been playing with gentoo linux a bit recently and it has a
command to take care of this. The idea seems simple enough: it looks
at the mtimes, and makes sure that it is never deleting a file which
belongs to the most recently installed version.
So what about doing something like this:
1. look at the mtimes of all the /var/db/pkg/foo-*
2. pick the second-most-recent of these (say, if you have foo-1.3.0,
1.3.1 and 1.3.2 installed in that order, take the mtime of foo-1.3.1)
3. Delete all files listed in +CONTENTS for foo-1.3.0 and foo-1.3.1 which
are older than this. (Since the package registration is the last
step, I assume that all files belonging to foo-1.3.1 will be older
than the files in /var/db/pkg/foo-1.3.1?)
Would this work, or is there some obvious problem here? It seems to
me that this is totally "safe" in that it will never delete a file
belonging to the most recent version (unless your clock was wrong
when it was installed). It may leave some older files intact if
they've been touched in the meantime.
There are other features I like about gentoo (I'll list them if anyone
is interested) but I think they would require major modifications to
the ports system (some of them are supported by portupgrade, though).
As it stands, I think the ports system is in some ways more intuitive
-- it's easier to do the configure, build etc yourself and supply your
own options on the way if you want to.
- Rahul
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Thu Jan 08, 2009 5:55 am | All times are GMT
|
|
Debt Consolidation | Carrinhos para bebê | Bad Credit Credit Cards | LG HD Ready Plasma TV | Debt Consolidation
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
BSD
»
FreeBSD
»
mail-lists
»
Architecture
