Date: Fri, 01 Aug 2008 17:27:40 +0200 From: Ivan Voras <ivoras@freebsd.org> To: freebsd-ports@freebsd.org Subject: Re: Call for comments - pkg_trans Message-ID: <g6va1g$5vd$1@ger.gmane.org> In-Reply-To: <4892B07A.60702@FreeBSD.org> References: <g6res0$giq$1@ger.gmane.org> <489144B5.4030101@FreeBSD.org> <g6sgqk$mcm$1@ger.gmane.org> <4892022F.1080009@FreeBSD.org> <9bbcef730807311438m45802827y91c7bb7366406af6@mail.gmail.com> <4892B07A.60702@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig93FC128FC54DAC5DCB2F6B31 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Doug Barton wrote: > Ivan Voras wrote: >> 2008/7/31 Doug Barton <dougb@freebsd.org>: >> >>> 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. >=20 > 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=20 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). >=20 > Thus my concern. :) >=20 >>> 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. >=20 > 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. >=20 > I seriously doubt that users would put up with that. Trying to think as= =20 > a user here, I certainly would not want to be told that in order to=20 > remove a port that I don't want I first have to remove one that I do.=20 > 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=20 stay because of N (I think I only need to notice that D2 is depended on=20 by something that isn't in the transaction being removed) * Remove M, D1, D3 from the transaction, leave only D2 in the=20 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=20 removed when N gets removed, but this is really out of scope for=20 pkg_trans - I'm not trying to solve complex interdependencies here :)=20 (or better said: I'm trying not to solve them...) --------------enig93FC128FC54DAC5DCB2F6B31 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIkytsldnAQVacBcgRAiFdAKDkMsyhwvZtdfK16E56pl0KAvG5AQCg24B2 37SUcXXBW7ZFgm5mLgjyq1g= =V83F -----END PGP SIGNATURE----- --------------enig93FC128FC54DAC5DCB2F6B31--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?g6va1g$5vd$1>