Re: Call for comments - pkg_trans
Miroslav Lachman wrote: Doug Barton wrote: Norberto Meijome wrote: [...] 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. ) portmaster has the --show-work option that gives you output like this: === Port directory: /usr/ports/sysutils/fusefs-ntfs === Starting check for all dependencies === Gathering dependency list for sysutils/fusefs-ntfs from ports === Installed archivers/unzip === Installed converters/libiconv === Installed devel/gmake === Installed devel/libtool15 === NOT INSTALLEDdevel/libublio === Installed devel/pkg-config === NOT INSTALLEDlang/ruby18 === NOT INSTALLEDsysutils/fusefs-kmod === NOT INSTALLEDsysutils/fusefs-libs === NOT INSTALLEDtextproc/ruby-deplate Is that what you had in mind? That is currently a separate operation because for ports with a lot of dependencies it can take a long time to build the list. But I suppose that if there is interest I could create a new mode of operation to do that check first, then confirm with the user that they want to proceed. Yes, it would be useful to me. Sometimes old ports comes with new default options and brings new dependencies which I do not want to have installed with update / upgrade of port, but it is not easy to track these changes. If portmaster will have option to firstly show above info about dependencies and wait for confirmation, I will use this feature. Maybe in combination with some advanced logic: if all dependencies are installed, continue without confirmation, if some dependency is missing, wait for my confirmation. What you think about it? Yes, this would definitely be very useful! BTW, I have a question (and a wish;)) -- if I specify multiple ports to install and portmaster fails to resolve some of them it aborts. I wish it would go on and install whatever ports it could resolve. More background -- I have a list of ports I always install. Using a little script I concatenate this list and pass it to portupgrade or portmaster after fresh system install. Now if there's a port which for instance was moved portupgrade will skip it and install everything else. portmaster, on the other hand, would simply fail. :-( With regards, Martin ___ 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 Fri, 1 Aug 2008 16:59:03 + (UTC)
Marcin Wisnicki [EMAIL PROTECTED] wrote:
Though it would be usefull to have a full log of package operations in
machine and human readable format for review/auditing and similar
purposes.
ah. nice thought. something that kicks in when /var/db/pkg/* is modified in any
way - independent of which application changes /var/db/pkg/* (not sure if this
can be implemented now...but maybe all of pkg_* , portmaster,etc can be
modified...).
I currently keep track of this using SVN and 2 test files : one with pkgs
installed + versions, and the other just with origin directories (which is more
useful when I want to know port was added or removed, rather than upgraded).
definitely more thinking needed...but i like where this is going ;)
B
_
{Beto|Norberto|Numard} Meijome
The music business is a cruel and shallow money trench, a long plastic hallway
where thieves and pimps run free, and good men die like dogs. There's also a
negative side. Hunter S. Thompson
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]
Re: Call for comments - pkg_trans
On Fri, 01 Aug 2008 17:27:40 +0200
Ivan Voras [EMAIL PROTECTED] wrote:
(Apologies for the mini top-post, and the confusing quotingis there a
mailer that will actually quote properly ? :P ) )
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.
Ivan V. said
Right, but D2 is still part of the transaction for N. If I roll back M
but leave N installed, then roll back N, D2 should be removed
(assuming for this example that D2 is not relevant to any other port).
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.
DB I seriously doubt that users would put up with that. Trying to think as
DB a user here, I certainly would not want to be told that in order to
DB remove a port that I don't want I first have to remove one that I do.
DB But perhaps I'm misunderstanding you again.
+1
This is a good point and I'm glad it's brought up. I think this will work:
* When user tries to roll back [M+D1+D2+D3], notice that D2 needs to
stay because of N (I think I only need to notice that D2 is depended on
by something that isn't in the transaction being removed)
right.
* Remove M, D1, D3 from the transaction, leave only D2 in the
transaction, as if only D2 was installed in it.
As you said, it would be best if D2 was then grouped with N so both get
removed when N gets removed, but this is really out of scope for
pkg_trans - I'm not trying to solve complex interdependencies here :)
(or better said: I'm trying not to solve them...)
Again, I am not sure the whole concept of transaction is needed after the
installation of M has finished successfully.
Of course, it'd be v useful (but configurable, pls!)
if when installing D1, D2, D3 , the process fails, and u are not left hanging
out with dependencies but not the intended package.
But once M and all its dependencies are installed... why not keep it
simple and figure out what you need to do via the dependencies? From Doug's
email, that's what postmaster seems to do (sorry, i haven't tried postmaster
yet).
It is very likely I am missing something, but not sure what it is.
cheers,
B
_
{Beto|Norberto|Numard} Meijome
I used to hate weddings; all the Grandmas would poke me and
say, You're next sonny! They stopped doing that when i
started to do it to them at funerals.
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]
Re: Call for comments - pkg_trans
On Thu, 31 Jul 2008 23:59:12 -0700
Doug Barton [EMAIL PROTECTED] wrote:
Norberto Meijome wrote:
On Thu, 31 Jul 2008 23:38:21 +0200 Ivan Voras
[EMAIL PROTECTED] wrote:
[...]
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.
As I mentioned previously portmaster has the -s option to remove ports
that were installed as dependencies but are no longer depended on. It
also has the -e option to expunge leaf ports you don't want anymore,
and -e will run 'portmaster -s' after it's done deleting the port you
specify on the command line.
Sounds great. Sorry, i don't use postmaster. Why? been using the
portupgrade/install/etc tools for longer; i actually like having different cmds
rather than parameters for everything ... silly things really.
I seem also to recall, from my usual read of several of the MLs, that more
people have issues dealing with dependencies when using postmaster than
portupgrade...which i hardly find with portupgrade. I do remember reading
someone's post (yours maybe? ) comparing postmaster to the portupgrade port and
the points raised where interesting- again, i haven't found most of the issues
raised in that post
(i just realised that most of the port-related cmds I use are from base,
maybe it is time for a change... ;) )
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. )
portmaster has the --show-work option that gives you output like this:
=== Port directory: /usr/ports/sysutils/fusefs-ntfs
=== Starting check for all dependencies
=== Gathering dependency list for sysutils/fusefs-ntfs from ports
=== Installed archivers/unzip
=== Installed converters/libiconv
=== Installed devel/gmake
=== Installed devel/libtool15
=== NOT INSTALLED devel/libublio
=== Installed devel/pkg-config
=== NOT INSTALLED lang/ruby18
=== NOT INSTALLED sysutils/fusefs-kmod
=== NOT INSTALLED sysutils/fusefs-libs
=== NOT INSTALLED textproc/ruby-deplate
Is that what you had in mind? That is currently a separate operation
because for ports with a lot of dependencies it can take a long time
to build the list.
right, but that is partly the point of having this information handy. Sometimes
one doesn't realise how much extra stuff is going to be installed.
In my case, I don't need/want kde, and have managed to stay out of its
libraries ways quite well...but it usually means having to check each ports
dependencies AND the dependencies' dependencies. Both the transaction support
for failed installations that Ivan is designing, and the --show-work option in
portmaster would address this.
But I suppose that if there is interest I could
create a new mode of operation to do that check first, then confirm
with the user that they want to proceed.
Right. for example, in a Centos 5 server :
$ yum install zenity
[...]
Dependencies Resolved
=
Package Arch Version RepositorySize
=
Installing:
zenity i386 2.16.0-2.el5 base 1.2 M
Installing for dependencies:
atk i386 1.12.2-1.fc6 base 222 k
cairo i386 1.2.4-5.el5 base 394 k
cups-libs i386 1:1.2.4-11.18.el5_2.1 updates
181 k
[]
scrollkeeperi386 0.3.14-9.el5 base 294 k
sgml-common noarch 0.6.3-18 base 40 k
xml-common noarch 0.6.3-18 base 5.8 k
xorg-x11-filesystem noarch 7.1-2.fc6base 5.4 k
Transaction Summary
=
Install 30 Package(s)
Update 0 Package(s)
Remove 0 Package(s)
Total download size: 14 M
Is this ok [y/N]:
The size of the installed package would be nice, but I don't think we can
provide that now. But the separation of {what you requested} vs {what is needed
for dependencies} , and the summary @ the end, is definitely good.
yes, by default would be nice for me (but since I'm not a portmaster user yet it
hardly matters too much :D ) , i think, with an override ( --no-summary ? ) to
bypass it.
Thanks for your time :)
B
_
{Beto|Norberto|Numard} Meijome
Law of Conservation of Perversity:
Re: Call for comments - pkg_trans
Norberto Meijome wrote:
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?
That is certainly how I would imagine it should work, yes.
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.
As I mentioned previously portmaster has the -s option to remove ports
that were installed as dependencies but are no longer depended on. It
also has the -e option to expunge leaf ports you don't want anymore,
and -e will run 'portmaster -s' after it's done deleting the port you
specify on the command line.
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. )
portmaster has the --show-work option that gives you output like this:
=== Port directory: /usr/ports/sysutils/fusefs-ntfs
=== Starting check for all dependencies
=== Gathering dependency list for sysutils/fusefs-ntfs from ports
=== Installed archivers/unzip
=== Installed converters/libiconv
=== Installed devel/gmake
=== Installed devel/libtool15
=== NOT INSTALLED devel/libublio
=== Installed devel/pkg-config
=== NOT INSTALLED lang/ruby18
=== NOT INSTALLED sysutils/fusefs-kmod
=== NOT INSTALLED sysutils/fusefs-libs
=== NOT INSTALLED textproc/ruby-deplate
Is that what you had in mind? That is currently a separate operation
because for ports with a lot of dependencies it can take a long time
to build the list. But I suppose that if there is interest I could
create a new mode of operation to do that check first, then confirm
with the user that they want to proceed.
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: Norberto Meijome wrote: [...] 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. ) portmaster has the --show-work option that gives you output like this: === Port directory: /usr/ports/sysutils/fusefs-ntfs === Starting check for all dependencies === Gathering dependency list for sysutils/fusefs-ntfs from ports === Installed archivers/unzip === Installed converters/libiconv === Installed devel/gmake === Installed devel/libtool15 === NOT INSTALLEDdevel/libublio === Installed devel/pkg-config === NOT INSTALLEDlang/ruby18 === NOT INSTALLEDsysutils/fusefs-kmod === NOT INSTALLEDsysutils/fusefs-libs === NOT INSTALLEDtextproc/ruby-deplate Is that what you had in mind? That is currently a separate operation because for ports with a lot of dependencies it can take a long time to build the list. But I suppose that if there is interest I could create a new mode of operation to do that check first, then confirm with the user that they want to proceed. Yes, it would be useful to me. Sometimes old ports comes with new default options and brings new dependencies which I do not want to have installed with update / upgrade of port, but it is not easy to track these changes. If portmaster will have option to firstly show above info about dependencies and wait for confirmation, I will use this feature. Maybe in combination with some advanced logic: if all dependencies are installed, continue without confirmation, if some dependency is missing, wait for my confirmation. What you think about it? 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
Hi, On Fri, Aug 1, 2008 at 12:04 AM, Marcin Wisnicki [EMAIL PROTECTED] wrote: 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. In the pkg_improved project http://wiki.freebsd.org/AndersNore/pkg_improved, Anders plan to add some new fields. Maybe he could add the USER_INSTALLED too :) 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. I like this way so much ! IMHO, it is the occasion to add these features in the userland, and by the way rewrite the pkg_tools according to these ideas : http://www.freebsd.org/projects/ideas/#p-ports-pkgtools / http://wiki.freebsd.org/libpkg http://www.freebsd.org/projects/ideas/#p-ports-upgrade Regards, Julien ___ 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
Norberto Meijome wrote:
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 '.
Yes, it's a good idea.
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. )
I like that in yum and have planned to include something like this. I'm
trying to decide should it be the default or not - for now, it probably
will be :)
signature.asc
Description: OpenPGP digital signature
Re: Call for comments - pkg_trans
Doug Barton wrote: Ivan Voras wrote: 2008/7/31 Doug Barton [EMAIL PROTECTED]: 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. No, portupgrade isn't mandatory, and it probably never will be because of ruby. It's only the most widely used and I think that any scheme that adds or changes to the behaviour of the ports infrastructure must also include portupgrade to be useful to the most users. At first glance these two statements seem contradictory, but I think what you meant in the second sentence is that for the new system to work portupgrade has to have support for it before it is rolled out. Yes :) If so, then I agree with you and would only add that authors of other ports management tools should be given adequate notice of the plans as well. Agreed. I suppose such authors read this list so will have plenty of time to catch up :) Note that, if I implement pkg_trans, any tool that doesn't know about it will, at best, generate useless single-package transactions (and at worst break the system, but I'll try hard to avoid this). Thus my concern. :) 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. Right, but D2 is still part of the transaction for N. If I roll back M but leave N installed, then roll back N, D2 should be removed (assuming for this example that D2 is not relevant to any other port). 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. I seriously doubt that users would put up with that. Trying to think as a user here, I certainly would not want to be told that in order to remove a port that I don't want I first have to remove one that I do. But perhaps I'm misunderstanding you again. This is a good point and I'm glad it's brought up. I think this will work: * When user tries to roll back [M+D1+D2+D3], notice that D2 needs to stay because of N (I think I only need to notice that D2 is depended on by something that isn't in the transaction being removed) * Remove M, D1, D3 from the transaction, leave only D2 in the transaction, as if only D2 was installed in it. As you said, it would be best if D2 was then grouped with N so both get removed when N gets removed, but this is really out of scope for pkg_trans - I'm not trying to solve complex interdependencies here :) (or better said: I'm trying not to solve them...) signature.asc Description: OpenPGP digital signature
Re: Call for comments - pkg_trans
Marcin Wisnicki wrote: 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. Wow, and I was afraid I'm doing an underkill here :) * 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. This has the same problems as my scheme and I'm not sure the benefits are the same. With pkg_trans, we know explicitly which packages were pulled in when, and the order in which they were pulled. * 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 Yes, with the exception that something needs to do pkg_create -b postgresql-8.3.0 before it's removed, and I don't trust myself to remember this every time :) (I want it to happen automatically) signature.asc Description: OpenPGP digital signature
Re: Call for comments - pkg_trans
On Fri, 01 Aug 2008 17:33:43 +0200, Ivan Voras wrote: Marcin Wisnicki wrote: On Thu, 31 Jul 2008 06:25:27 +0200, Ivan Voras wrote: 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. This has the same problems as my scheme But is simpler both conceptually and in implementation and I'm not sure the benefits are the same. With pkg_trans, we know explicitly which packages were pulled in when, and the order in which they were pulled. Well I'm not sure why any user would care about order and it can be inferred from mtime of package metadata or new +comment DATE (see http://blogs.freebsdish.org/andenore/) anyway. What is important is to know: 1. Which packages are important to user (most likely the those that he installed explicitly) 2. Which packages can be safely removed = everything that is not (1) or isn't a dependancy of (1) * 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 Yes, with the exception that something needs to do pkg_create -b postgresql-8.3.0 before it's removed, and I don't trust myself to remember this every time :) (I want it to happen automatically) Or save the package during installation. Like portugprade. Anyway, it is a separate problem. ___ 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 Fri, 01 Aug 2008 16:51:02 +, Marcin Wisnicki wrote: On Fri, 01 Aug 2008 17:33:43 +0200, Ivan Voras wrote: Marcin Wisnicki wrote: On Thu, 31 Jul 2008 06:25:27 +0200, Ivan Voras wrote: 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. This has the same problems as my scheme But is simpler both conceptually and in implementation and I'm not sure the benefits are the same. With pkg_trans, we know explicitly which packages were pulled in when, and the order in which they were pulled. Well I'm not sure why any user would care about order and it can be Though it would be usefull to have a full log of package operations in machine and human readable format for review/auditing and similar purposes. inferred from mtime of package metadata or new +comment DATE (see http://blogs.freebsdish.org/andenore/) anyway. ___ 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, 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: 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: 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: 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]
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]
Re: Call for comments - pkg_trans
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 :) 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 things it does now already are to save binary packages before running pkg_delete, and it has the ability to roll back installation of ports you no longer want, along with all dependencies related to those ports that become obsolete. Take a look at the -e and -s options for the latter, and the -b and -g options for the former. By default portmaster saves the backup packages until the current round of updates is done, then if the user hasn't specified the -b option they get deleted before portmaster exits. 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 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. As I said though, portmaster already has the capability to do two things you say you want to support, albeit the rollback operation would have to be done manually. I think it would be pretty simple to add support for an undo feature when it comes to upgrading something in place and/or deleting existing stuff as long as you don't expect the ability to undo that particular transaction to last longer than the time period until you modify something that was part of it. I think undo for a new installation is harder for the reasons I mentioned above, but the good news is that it's already possible to do most of that just using the existing ports infrastructure. 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]
