Date: Wed, 15 Jan 2014 07:35:08 +0000 From: Matthew Seaman <matthew@FreeBSD.org> To: Polytropon <freebsd@edvax.de>, FreeBSD Questions <freebsd-questions@freebsd.org> Subject: Re: Combining pkg and "traditional ports" Message-ID: <52D63A2C.2060806@FreeBSD.org> In-Reply-To: <20140115063634.d6d26d51.freebsd@edvax.de> References: <20140115063634.d6d26d51.freebsd@edvax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --icXSreqtW5illBeBmrm1TbL2VxAQsl92r Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 15/01/2014 05:36, Polytropon wrote: > With the upcoming OS standardization on pkg (pkgng) following > the abolishment of the pkg_* toolset I'd like to ask questions > to those who already actively use pkg and have probably encountered > and solved the same "problems" that I'll be expecting: >=20 > There are two cases where a binary package can't be used: >=20 > a) There is no package. >=20 > Not all ports have equivalent packages. For example, I've seen > this recently for OpenArena. In this case, compiling is needed > (and even switching to gcc instead of clang, OS v10-RC2). Another > example is a localize OpenOffice / maybe LibreOffice. >=20 > How is this handled when a pkg-based "upgrade all" is performed? Packages installed on your local system but not available from any of your configured repositories are just left untouched by the upgrade process. If your local package 'foo' depends on a package 'bar' from the repo, and upgrading the dependency 'bar' would cause problems ideally, you'ld see an error message from pkg saying in essence "I want to upgrade bar, but foo is blocking that." Unfortunately, I don't think that would happen in all cases at the moment. > b) The default options of the package can't be used. >=20 > My favourite example is mplayer (including all imaginable > codecs as well as mencoder and additionally the gmplayer > and gmencoder X applications), but it could also apply for > a HAL-less X and HAL-less applications. But also OpenOffice > can be considered again, a localized version (german) with > dependencies for KDE, Gnome and CUPS deactivated (because I > don't use those). >=20 > Can those be protected from being overwritten? The general solution to this problem is to set up your own package repository using eg. poudriere -- you don't have to build everything you need installed, just the ports where you want customised options and everything they depend on. You can force a package to only be updated from a specific repo by using pkg annotate -- details are in pkg-repository(5). Unfortunately there is no obvious way to have a local repo for just eg. OpenOffice without also including everything that OpenOffice depends on. That would be a useful enhancement to poudriere if anyone is looking for a programming project -- fetch all dependencies from another repo except the packages you specifically want to build. There is not, at the moment, any way of treating 'install from ports' in a similar way. I've seen some ideas floating around on IRC, but nothing concrete in the code yet. > Is there even a method of saying, like, "use binary packages > to upgrade everything excepts ports 'foo', 'bar', 'meow' and > 'moo', compile those, but make sure their dependencies are > installed via packages when they are available and apply"? You can use 'pkg lock' against your hand-installed ports, which will prevent pkg overwriting them, but then you'ld have to remember to unlock before running portmaster or whatever. > From my experience so far, pkg works really great. I'd just > like to know how it can be used in the few cases where the > exceptions need to be made intendedly. pkg design is still in a very fluid phase -- some things have been pretty much settled, but a large part of the way it behaves is still to be finalized. We will be very interested to hear about different use cases, and where pkg either doesn't fulfil your needs or match up to your expectations (within reason). Although you should accept that some things do work differently to the way the old pkg_tools did, and just being different, although it may be surprising to you, is not automatically a fault. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --icXSreqtW5illBeBmrm1TbL2VxAQsl92r Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJ8BAEBCgBmBQJS1jo/XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkATdHIP/jcWyNxOfs+vQ1xgIaF5cKup vUOu9ok6+X479EHd/6lw8WLJBBae2IKae+NwQ5t3dqrATzHQBq0UTMmfOya0FErc /hXQUwtNSn4HNO3gE1D5iKqb3VM2zjxakK59BsaKmJ5gP4KsqkA9Muktb4QScmYp jCJYyNEiv3+wLgcSg9Nf5IK5s6SGtt5MUWcr7iqoO0enbJgOUkWLrH4ptFUtYKuU 1La3FWyak40zmHFib+USTdvjf1Z7sfSERXalEuh2dOZsFwxy2FOlpFqYb3/9Idl/ SeBqpc24MctuZB6o+iaPpU6RbHYxq7PGCga+p0Zj/GTLw4dQdRLV9qJZPOaKidEu 3UBtGxZhn7eHjZVIrIxpiIKYjDn7p70ErWwcOauPZ1LNbYdTzf4b2grR3fXh3aWG woJwjVYu60lfD5p6ihTHm9OKJbcmpuX19iF0FK/dSSTMJW08vNPZY+NPfzuRLI9z W+tVkSkoxy40g7NNullg3BlbXvJsDyHbdym81Nx9aXlkIrensVVwqFlCgo86PInv K/F9qpkMKFnx2zm5b6HC08aynMs0eGlROmpOfLXDEhJ9B9v4s7mbBpMZjnG7os5O NQrX+ApsGI2h+dI3r5DwCPNFZQKeLiOm8IcRK+dfMWZ7SszxpWhqUkejhpWDnZ9+ KGYkrkSZx7DU0/GrIoUW =6kul -----END PGP SIGNATURE----- --icXSreqtW5illBeBmrm1TbL2VxAQsl92r--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52D63A2C.2060806>