Re: Call for comments - pkg_trans
On Thu, Jul 31, 2008 at 06:25:27AM +0200, Ivan Voras wrote: Hi, I apologize in advance if what I'm trying to do seems stupid or it has already existed since the Dawn of Time (i.e. when McKusick was in diapers) but I'd like your comments on this idea: http://wiki.freebsd.org/IvanVoras/PkgTransProposal I can write the pkg_trans utility and modify the C utilities (pkg_add, pkg_delete, if they're sane) but I can't do makefiles and ruby, so if this is to work, I'll need some help :) This looks quite cool, especially the fact that it'd be tied into pkg_add and pkg_delete. By makefiles are you referring to the ports/Mk stuff, or are you referring to actual Makefiles for src/usr.sbin/pkg_install (which is ultimately where pkg_trans should go)? And I assume by ruby you're referring to the portupgrade tie-ins. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with portupgrade xscreensaver-gnome
In response to Doug Barton [EMAIL PROTECTED]: Bill Moran wrote: It's a combination of a number of issues: 1) The ports infrastructure shouldn't let you set options that don't make sense. I think that one could argue that it should be _hard_ to set options that don't make sense, but I don't think it should be impossible. you have to keep in mind that we cater to a very diverse user community, from rank beginners to advanced hackers. True. My opinion: A GUI that _prevents_ novice users from selecting incompatible options is a good idea. Expert users can always manually tweak /var/db/ports/ files if they want to override those restrictions. 2) Why is portupgrade dying on a warning message? Why does a poor decision on one port prevent everything on my system from upgrading? For the same reason that portmaster dies on errors, neither program is omniscient. :) If ports tools hit a point where it's not clear how to proceed they _should_ stop and get user input. The next thing the users generally say is that it should somehow proceed with the rest of the upgrade, finish things that don't rely on the broken bits, etc. Unfortunately that is quite a bit harder to do than you might think, although patches are always welcome. Understood. But keep in mind that this was not an error, it was a warning. Perhaps the ports infrastructure doesn't differentiate between those two as much as I think. 3) The error from portupgrade does not immediately point me to the easy solution, it tricks me into thinking I have to hack the Makefile. I don't actually think that the error message you're referring to is from portupgrade, I think it's from the port itself. I can see that. -- Bill Moran http://www.potentialtech.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with portupgrade xscreensaver-gnome
On Wed, 30 Jul 2008 17:42:33 -0500, Jeremy Messenger wrote: On Wed, 30 Jul 2008 17:09:11 -0500, Marcin Wisnicki [EMAIL PROTECTED] wrote: If .warning breaks portupgrade I can change it to IGNORE. I prefer remove .warning and IGNORE. If user wants to enable keyring then the WITH_KEYRING should be always enable PAM, no matter if user has selected it disable. And, tweak comment in OPTIONS for (reqiure PAM). OK, I've sent patches to PR. http://www.freebsd.org/cgi/query-pr.cgi?pr=126114 As suggested, .warning was removed, option description improved and KEYRING will force PAM. http://www.freebsd.org/cgi/query-pr.cgi?pr=126115 Like above, gnome-screensaver has similar .warning, but because of partially broken pam support, the logic is reversed: lack of pam will disable keyring. Also I've introduced some anti foot-shooting measures until the problem is fixed, so users of g-s won't end up with broken setup by selecting wrong options. Maybe options should be hidden behind GNOME_SCREENSAVER_WITH_BROKEN_PAM conditional ? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Call for comments - pkg_trans
Jeremy Chadwick wrote: On Thu, Jul 31, 2008 at 06:25:27AM +0200, Ivan Voras wrote: Hi, I apologize in advance if what I'm trying to do seems stupid or it has already existed since the Dawn of Time (i.e. when McKusick was in diapers) but I'd like your comments on this idea: http://wiki.freebsd.org/IvanVoras/PkgTransProposal I can write the pkg_trans utility and modify the C utilities (pkg_add, pkg_delete, if they're sane) but I can't do makefiles and ruby, so if this is to work, I'll need some help :) This looks quite cool, especially the fact that it'd be tied into pkg_add and pkg_delete. By makefiles are you referring to the ports/Mk stuff, or are you referring to actual Makefiles for src/usr.sbin/pkg_install (which is ultimately where pkg_trans should go)? I'm thinking of ports/Mk - I suspect it will get hairy to add pkg_trans to the make install and similar processes on the ports. And I assume by ruby you're referring to the portupgrade tie-ins. Yes. signature.asc Description: OpenPGP digital signature
Re: Problems with portupgrade xscreensaver-gnome
On Thu, 31 Jul 2008 08:16:28 -0400 Bill Moran [EMAIL PROTECTED] wrote: In response to Doug Barton [EMAIL PROTECTED]: For the same reason that portmaster dies on errors, neither program is omniscient. :) If ports tools hit a point where it's not clear how to proceed they _should_ stop and get user input. The next thing the users generally say is that it should somehow proceed with the rest of the upgrade, finish things that don't rely on the broken bits, etc. Unfortunately that is quite a bit harder to do than you might think, although patches are always welcome. Understood. But keep in mind that this was not an error, it was a warning. Perhaps the ports infrastructure doesn't differentiate between those two as much as I think. It's actually nothing to do with the ports infrastructure, this has no effect on a normal manual build, or on portmaster. The warning is treated as an error by portupgrade. If you remove the 21 redirection in line 1463 of portupgrade, the port will be built. I don't know if it has a good reason for treating writes to stderr as fatal errors, or not. No other port uses .warning, they all use echo or IGNORE. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Call for comments - pkg_trans
Doug Barton wrote: You have some very interesting ideas there. Not that I want to dissuade you in any way from doing this, but I would like to point out that portmaster already does some of what you're suggesting and it could fairly easily be modified to do just about all the rest of it. The two I really want the standard ways of installing and upgrading packages (make install, portinstall) to support those features. In terms of the rest of your proposal, off the top of my head the transaction IDs should probably be saved in /var/db/ports. I need to think harder about what format you could probably have a /var/db/ports/trans/ and then save the logs of the transactions as individual files by transaction ID. The wheels are spinning in my mind I don't think this is a big problem. I have an idea how to record this data. right now about how this could get hairy down the road when you install a bunch of stuff as dependencies for fooport, then you start doing upgrades on the individual dependencies the log of the transaction quickly becomes less valuable. Some thought would have to be given to exactly what the goals are, how long those logs should be valid/useful, etc. Yes, rolling back old transactions, after individual packages in them have been updated will be a problem. I see a way out of it if only portupgrade is used for the upgrading so information exists about which package is upgraded by which. signature.asc Description: OpenPGP digital signature
Re: Call for comments - pkg_trans
Ivan Voras wrote: Doug Barton wrote: You have some very interesting ideas there. Not that I want to dissuade you in any way from doing this, but I would like to point out that portmaster already does some of what you're suggesting and it could fairly easily be modified to do just about all the rest of it. The two I really want the standard ways of installing and upgrading packages (make install, portinstall) to support those features. What is your point of view for standard ways? For me, portinstall/portupgrade is not part of the base, so it can be hardly more standard than portmaster (or other tools). And as time goes by portupgrade has more and more issues with dependencies etc., that I am migrating to portmaster... It means - portmaster is my standard way of installing, portupgrade is your standard way, but only make install and pkg_add are official ways included in base. So... I think there must be hooks in ports system and pkg_add itself, that any other install / upgrade tool will use it automatically. Anyway, your proposal is useful. It would be nice to have it in the base or in some tool(s) from ports. Miroslav Lachman ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Call for comments - pkg_trans
Ivan Voras wrote: I apologize in advance if what I'm trying to do seems stupid or it has=20 already existed since the Dawn of Time (i.e. when McKusick was in=20 diapers) but I'd like your comments on this idea: http://wiki.freebsd.org/IvanVoras/PkgTransProposal I can write the pkg_trans utility and modify the C utilities (pkg_add,=20 pkg_delete, if they're sane) but I can't do makefiles and ruby, so if=20 this is to work, I'll need some help :) I find this idea fantastic! This is much needed in the FreeBSD ports system. In fact without such a mechanism, it is difficult to have a reasonably good upgrade system. For example suppose you install KDE, and as a dependency some software is installed. In a new version of KDE this software has been abandoned and replaced by more modern stuff (example fam - gamin). If both still exist in the ports system, without your mechanism, both will be upgraded regularly. Keeping state on things which have been installed as dependencies and thus can be removed if the dependency is no more present is necessary. Of course it is also a convenience for the end user. As to the necessary modifications in portupgrade, perhaps not a lot if the basic tools (pkg_add, etc.) work correctly by themselves, since portupgrade mainly calls these tools. But of course, injecting the above state information in pkgdb.db would perhaps be useful. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with portupgrade xscreensaver-gnome
Bill Moran wrote: Understood. But keep in mind that this was not an error, it was a warning. Perhaps the ports infrastructure doesn't differentiate between those two as much as I think. The use of the make .warning trick is deprecated in the ports tree precisely because it leads to confusion. In this case the warning was telling you that you had options selected which conflicted, and the proper course of action for portupgrade was indeed to bail. Continuing to focus on the semantics isn't really productive. Doug -- This .signature sanitized for your protection ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Call for comments - pkg_trans
Ivan Voras wrote: Doug Barton wrote: You have some very interesting ideas there. Not that I want to dissuade you in any way from doing this, but I would like to point out that portmaster already does some of what you're suggesting and it could fairly easily be modified to do just about all the rest of it. The two I really want the standard ways of installing and upgrading packages (make install, portinstall) to support those features. type portinstall bash: type: portinstall: not found H, I guess that's not so standard after all. :) Seriously though, I don't want to get into a ports-tool debate. I was explicit in saying that I don't want to dissuade you from adding this support to the pkg_* tools. My point is that there are already ways to do some of what you're suggesting, and you may be able to leverage that. right now about how this could get hairy down the road when you install a bunch of stuff as dependencies for fooport, then you start doing upgrades on the individual dependencies the log of the transaction quickly becomes less valuable. Some thought would have to be given to exactly what the goals are, how long those logs should be valid/useful, etc. Yes, rolling back old transactions, after individual packages in them have been updated will be a problem. I see a way out of it if only portupgrade is used for the upgrading so information exists about which package is upgraded by which. As I'm sure you can imagine, I would not regard any solution that says portupgrade is mandatory very favorably, and I don't think I'd be alone there. What you need to be doing here is to define the API so that whatever tool(s) the user chooses can interact with the system. BTW, I thought of another problem scenario. The user installs port M, and it brings dependencies D1, D2, and D3. Then the user installs port N which also has port D2 as a dependency. The more I think about this idea of transactions as chunks of stuff that can be reversed together the more I think that this facility probably needs to be time-constrained, or at minimum have very good support for invalidating itself to avoid problems with scenarios like the one I described above. To continue brainstorming, it might be useful to combine the strategy that portmaster uses with a variation of your idea. If you take a look at the categories portmaster uses to define ports (roots, trunks, branches, and leaves) the first is a port with no dependencies, up or down; and the last is a port that has dependencies but is not depended on. If the transaction log only recorded the root and leaf ports those could easily be rolled back together and then you could use the logic from portmaster's -s option to handle deleting stale dependencies. This would still require some care to maintain since ports that are roots or leaves today might become trunks or branches tomorrow, but it would require less maintenance than trying to keep track of everything. hth, Doug -- This .signature sanitized for your protection ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Call for comments - pkg_trans
Doug Barton wrote: BTW, I thought of another problem scenario. The user installs port M, and it brings dependencies D1, D2, and D3. Then the user installs port N which also has port D2 as a dependency. Then D2 becomes available for deletion only after M and N have been deleted or no more require it. I don't see a big problem here. Perhaps it is however a problem for the notion of transaction, since a group of ports flagged for deletion by a transaction cannot be entirely removed after some time when part of it is needed by other ports. This means one needs to keep a very complete and detailed data basis of the operations, of course. By the way, on the course of time, ports belonging on a transaction are upgraded, may change name (according to the MOVED file) so one also have to continually update this information in the data basis. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Call for comments - pkg_trans
On Thu, 31 Jul 2008 06:25:27 +0200, Ivan Voras wrote: Hi, I apologize in advance if what I'm trying to do seems stupid or it has already existed since the Dawn of Time (i.e. when McKusick was in diapers) but I'd like your comments on this idea: http://wiki.freebsd.org/IvanVoras/PkgTransProposal Looking at your use cases I think what you are proposing is overkill. * Install some large group of packages, like KDE or GNOME. Don't like it, want to delete all packages installed during the operation. This could be achieved by tracking which ports were installed explicitly by user. I.e. when I type: (cd /usr/ports/x11/gnome2; make install) or pkg_add -r gnome2 It will install gnome2 along with it's dependencies but in some way mark gnome2 package as installed by user, say, by creating /var/db/pkg/ gnome2-2.22/+USER_INSTALLED or even easier, by maintaing some special unremovable dummy package that would depend on all packages installed explicitly. Then when you decide you want to get rid of gnome something like this could be implemented: pkg_deinstall -Ru gnome2-2.22 where option 'R' (already exists in pkg_deinstall but could be added to pkg_delete) means Deinstall all those packages required by the given packages as well. and option 'u' would be something like keep packages installed explicitly. I think similar solution is/was used in Gentoo. You can even approximate this behaviour with existing tools like pkg_rmleaves or pkg_cutleaves, though you will need to manually maintain a list of packages to keep. * Install a newer version of postgresql, have an OMG moment and remember you need to dump the database with the old version and reaload it with the new version. Revert the install by deleting the new packages and reinstalling the old ones (i.e. undo a removal). pkg_deinstall -R posgtresql-8.4.0; pkg_add postgresql-8.3.0 but you still need to figure out how to get old packages (portupgrade/ portinstall with option -P keeps all packages on disk). Also if not all dependencies of postgres84 could be removed (because some other package needs them) then you could have a problem in either of schemes (yours and mine). ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Unable to make install on Subversion port
Hello everybody, I've been trying to install subversion for a few days but it just won't work. I can do make config, make all but when I do make install, it eventually freeze at: chmod 755 /usr/local/libexec/apache22/mod_dav_svn.so I let it like that for an entire day and it never moved. If I check my process list, here's a list of what's running: --- root 43123 0.0 0.0 1048 888 p0 I+ 2:24PM 0:00.05 make config all install clean root 43319 0.0 0.0 1708 980 p0 I+ 2:25PM 0:00.00 /bin/sh -ec cd /usr/ports/devel/subversion make CONFIG_DONE=1 /usr/ports/devel/subversion/work/.install_done.subversion._usr_local root 43320 0.0 0.0 1088 932 p0 I+ 2:25PM 0:00.06 make CONFIG_DONE=1 /usr/ports/devel/subversion/work/.install_done.subversion._usr_local root 43457 0.0 0.1 2552 2400 p0 I+ 2:25PM 0:00.09 make -f Makefile install root 51284 0.0 0.0 1712 988 p0 I+ 2:25PM 0:00.00 /bin/sh -ec cd subversion/mod_dav_svn ; /usr/bin/install -c -o root -g wheel -d /usr/local/libexec/apache22 ; /usr/local/sbin/apxs -i -S LIBEXECDIR=/usr/local/libexec/apache22 -a -n dav_svn mod_dav_svn.la --- If I compile Subversion without MOD_DAV_SVN and APACHE2_APR, it compiles and install fine. But with those two options (which are required in my setup), it stalls. I tried many things, like recompiling apache and redownloading the ports. No luck. Any help would be greatly appreciated. Thanks! -- Pierre-Luc Brunet ZeStuff 1367 Bergar Laval, Quebec Canada, H7L 4Z7 T: 866-881-0250 - 450-662-0250 F: 450-662-0200 E: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] W: http://www.zestuff.com http://www.zestuff.com Follow us on Twitter! http://www.twitter.com/ZeStuff ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Call for comments - pkg_trans
On Thu, 31 Jul 2008 23:38:21 +0200
Ivan Voras [EMAIL PROTECTED] wrote:
BTW, I thought of another problem scenario. The user installs port M, and it
brings dependencies D1, D2, and D3. Then the user installs port N which also
has port D2 as a dependency.
Port N then won't install D2 as it already exists. The user can
rollback [N], then rollback [M+D1+D2+D3]. Trying to roll back back
[M+D1+D2+D3] before [N] will show the user a message about
dependencies.
Shouldn't you be able to request rollback [M + D1 + D2+ D3 ] , but have the
dependency of {something else not M} on D2 be detected, and therefore D2 *not*
uninstalled?
you'd end up then with M, D1, D3 removed , D2 still installed (as N needs it),
and a message saying 'D2 was not removed due to existing dependencies : N '.
As a matter of fact, i don't really see why we need a transaction system to
have an option to {pkg management of choice} to uninstall {unwanted_pkg} and
all other dependencies ONLY needed by {unwanted_pkg}. Anyway, pkg_cutleaves
does part of it...but it'd be much handier, i think, to handle it @ the
uninstall time.
And since we are just wishing for things, It'd be nice to have an opportunity
to back off from a install/remove after calculating dependencies, such as that
provided by yum (it shows everything it will do and asks for confirmation
before proceeding. )
B
PS: Thanks for all great work + time put into all the ports + base!!
_
{Beto|Norberto|Numard} Meijome
Mind over matter: if you don't mind, it doesn't matter
I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
