| Both sides previous revision Previous revision Next revision | Previous revision |
| ports:todo [2011/07/03 20:10] – Add Pav's negative opinion on removal of ${PORTSDIR} from dependencies ChrisRees | ports:todo [2023/01/29 14:08] (current) – man.freebsd.org GrahamPerrin |
|---|
| * Conference paper about package management (with comparison and ideas): [[http://people.freebsd.org/~sat/pmp/papref.pdf|PDF]] [[http://people.freebsd.org/~sat/pmp/papref|TXT]]. | * Conference paper about package management (with comparison and ideas): [[http://people.freebsd.org/~sat/pmp/papref.pdf|PDF]] [[http://people.freebsd.org/~sat/pmp/papref|TXT]]. |
| * [[http://www.dinoex.de/schulungen/package-en.html|Lightweight FreeBSD package cluster in a jail]] (:!: TODO: take ideas from here). | * [[http://www.dinoex.de/schulungen/package-en.html|Lightweight FreeBSD package cluster in a jail]] (:!: TODO: take ideas from here). |
| * [[/Upak|Upak]] (effort to unify packages). | * [[AndrewPantyukhin/Upak]] (effort to unify packages). |
| * [[http://lwn.net/Articles/240399/|Package management in Gentoo Linux]]. | * [[http://lwn.net/Articles/240399/|Package management in Gentoo Linux]]. |
| |
| === File-less dependencies === | === File-less dependencies === |
| |
| Allow to omit it, or add new dependency variables which don't require it, as it's a common case for meta-ports, ports that can install different mutually exclusive files, and future possible virtual ports. This could be done the same way as with current versioned dependencies: passing to [[http://www.freebsd.org/cgi/man.cgi?query=pkg_info&apropos=0&sektion=0&manpath=FreeBSD+6.3-RELEASE+and+Ports&format=html|pkg_info(1)]]. See [[http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1#doc_chap5|Gentoo dependencies]], which also have similar (actually more powerful) fuctionality as in %%FreeBSD%% (see [[http://www.freebsd.org/cgi/man.cgi?query=pkg_glob&apropos=0&sektion=0&manpath=FreeBSD+6.3-RELEASE+and+Ports&format=html|pkg_glob(1)]]). | Allow to omit it, or add new dependency variables which don't require it, as it's a common case for meta-ports, ports that can install different mutually exclusive files, and future possible virtual ports. This could be done the same way as with current versioned dependencies: passing to [[http://man.freebsd.org/cgi/man.cgi?query=pkg_info&apropos=0&sektion=0&manpath=FreeBSD+6.3-RELEASE+and+Ports&format=html|pkg_info(1)]]. See [[http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1#doc_chap5|Gentoo dependencies]], which also have similar (actually more powerful) fuctionality as in %%FreeBSD%% (see [[http://man.freebsd.org/cgi/man.cgi?query=pkg_glob&apropos=0&sektion=0&manpath=FreeBSD+6.3-RELEASE+and+Ports&format=html|pkg_glob(1)]]). |
| |
| :idea: //Implementation:// some lines of make code in ''%%bsd.port.mk%%'' to check ''%%/var/db/pkg%%'' if ":" isn't present in dependency line. | :idea: //Implementation:// some lines of make code in ''%%bsd.port.mk%%'' to check ''%%/var/db/pkg%%'' if ":" isn't present in dependency line. |
| |
| A ''%%LICENSE%%'' variable could be set in each port, as in Gentoo, and then have a "license pool" directory with all of them. IIRC in PC-BSD's PBI packages a license agreement is presented to the user in the setup, and this could benefit them too. | A ''%%LICENSE%%'' variable could be set in each port, as in Gentoo, and then have a "license pool" directory with all of them. IIRC in PC-BSD's PBI packages a license agreement is presented to the user in the setup, and this could benefit them too. |
| |
| See [[/PortsAndGPLv3|PortsAndGPLv3]]. | |
| |
| :idea: //Implementation:// add the variable and a directory to place licenses (subdirectory ''%%licenses%%'' under ports?). | :idea: //Implementation:// add the variable and a directory to place licenses (subdirectory ''%%licenses%%'' under ports?). |
| Currently to build a packages these systems recreate the chroot environment from an archive. This is to ensure each port is built in a clean environment. The deletion/extraction of chroots takes time, and the changes that remain are minimal (as ports are deinstalled for checking correctness and the extra/missing files check). | Currently to build a packages these systems recreate the chroot environment from an archive. This is to ensure each port is built in a clean environment. The deletion/extraction of chroots takes time, and the changes that remain are minimal (as ports are deinstalled for checking correctness and the extra/missing files check). |
| |
| So it could be turned into a clean environment a program like [[http://www.freebsd.org/cgi/man.cgi?query=rsync&apropos=0&sektion=0&manpath=FreeBSD+6.3-RELEASE+and+Ports&format=html|rsync(1)]]. It would require having an extracted chroot somewhere else, or a virtual FS mounted from the chroot archive. Also ''%%mount_unionfs%%'' (stable as of %%FreeBSD%% 7) could be used to keep the original chroot clean and save space (and easing other tasks as detecting new/changed/missing files). See also [[http://www.freshports.org/sysutils/fusefs-unionfs/|sysutils/fusefs-unionfs]] as a possible alternative. | So it could be turned into a clean environment a program like [[http://man.freebsd.org/cgi/man.cgi?query=rsync&apropos=0&sektion=0&manpath=FreeBSD+6.3-RELEASE+and+Ports&format=html|rsync(1)]]. It would require having an extracted chroot somewhere else, or a virtual FS mounted from the chroot archive. Also ''%%mount_unionfs%%'' (stable as of %%FreeBSD%% 7) could be used to keep the original chroot clean and save space (and easing other tasks as detecting new/changed/missing files). See also [[http://www.freshports.org/sysutils/fusefs-unionfs/|sysutils/fusefs-unionfs]] as a possible alternative. |
| |
| ==== Improving OPTIONS ==== | ==== Improving OPTIONS ==== |
| |
| See [[/RewriteOfOptions|RewriteOfOptions]] and [[http://www.freebsd.org/projects/ideas/#p-ports-options|Project Ideas entry]]. | See [[http://www.freebsd.org/projects/ideas/#p-ports-options|Project Ideas entry]]. |
| |
| In addition, I would suggest: | In addition, I would suggest: |
| === Binary compatibility (amd64/ia64 -> i386) === | === Binary compatibility (amd64/ia64 -> i386) === |
| |
| The recent ''%%DESTDIR%%'' functionality could be used for this (like a ''%%/compat/freebsd-i386%%'' chroot), the Linux emulation approach would work fine. For the ports side, dependencies would have to be built in the corresponding chroot or using packages, and //leaf// ports installed normally, but executed in the chroot. This would require kernel changes, otherwise i386 programs could simply be installed there, and the user could use [[http://www.freebsd.org/cgi/man.cgi?query=mount_nullfs&apropos=0&sektion=0&manpath=FreeBSD+6.3-RELEASE&format=html|mount_nullfs(8)]] to access the real root from there. In either case, individual ports wouldn't have to change. | The recent ''%%DESTDIR%%'' functionality could be used for this (like a ''%%/compat/freebsd-i386%%'' chroot), the Linux emulation approach would work fine. For the ports side, dependencies would have to be built in the corresponding chroot or using packages, and //leaf// ports installed normally, but executed in the chroot. This would require kernel changes, otherwise i386 programs could simply be installed there, and the user could use [[http://man.freebsd.org/cgi/man.cgi?query=mount_nullfs&apropos=0&sektion=0&manpath=FreeBSD+6.3-RELEASE&format=html|mount_nullfs(8)]] to access the real root from there. In either case, individual ports wouldn't have to change. |
| |
| ==== More automatizations ==== | ==== More automatizations ==== |
| |
| - Running setup scripts (i.e. like ''%%post-install%%''), both system and user level (replacing ''%%make install-user%%'' for some ports). Some even have knobs/OPTIONS to choose doing this or not. By delegating to this tool, the user can choose to do it automatically or manually. | - Running setup scripts (i.e. like ''%%post-install%%''), both system and user level (replacing ''%%make install-user%%'' for some ports). Some even have knobs/OPTIONS to choose doing this or not. By delegating to this tool, the user can choose to do it automatically or manually. |
| - Assist in merging configuration files. By running [[http://www.freebsd.org/cgi/man.cgi?query=sdiff&apropos=0&sektion=0&manpath=FreeBSD+6.3-RELEASE&format=html|sdiff(1)]], used by mergemaster. Even a more complex script/program could be made to compare and try to integrate the 3 files (old default config, new default config, and current config). See [[http://gentoo-wiki.com/HOWTO_etc-update|Gentoo etc-update]]. | - Assist in merging configuration files. By running [[http://man.freebsd.org/cgi/man.cgi?query=sdiff&apropos=0&sektion=0&manpath=FreeBSD+6.3-RELEASE&format=html|sdiff(1)]], used by mergemaster. Even a more complex script/program could be made to compare and try to integrate the 3 files (old default config, new default config, and current config). See [[http://gentoo-wiki.com/HOWTO_etc-update|Gentoo etc-update]]. |
| - Add corresponding lines to /etc/rc.conf (maybe commented), remove, etc. See [[http://gentoo-wiki.com/Rc-update|Gentoo rc-update]]. | - Add corresponding lines to /etc/rc.conf (maybe commented), remove, etc. See [[http://gentoo-wiki.com/Rc-update|Gentoo rc-update]]. |
| - Keep track of which ports need configuration file updating, initial setup, have ''%%pkg-message%%'', etc. | - Keep track of which ports need configuration file updating, initial setup, have ''%%pkg-message%%'', etc. |
| In these cases most of the information present in the port could be obtained from these //subsystems// (like ''%%pkg-descr%%'', dependencies, etc) and avoid creating and updating these kinds of ports (only a list of the ones which are used would be needed, and in the worst case a patch for it). For the Linux compatibility we could use the package management system of the distribution installed in ''%%/compat/linux%%''. | In these cases most of the information present in the port could be obtained from these //subsystems// (like ''%%pkg-descr%%'', dependencies, etc) and avoid creating and updating these kinds of ports (only a list of the ones which are used would be needed, and in the worst case a patch for it). For the Linux compatibility we could use the package management system of the distribution installed in ''%%/compat/linux%%''. |
| |
| See [[http://wiki.freebsd.org/Upak/PMS_Links|this page]] for links to the mentioned subjects. | See [[Upak/PMS_Links|this page]] for links to the mentioned subjects. |
| |
| === Self testing of packages === | === Self testing of packages === |
| The tags are managed by a program, it just has to be integrated with other tools (say, a tag-aware ''%%portsearch%%''). About packages that can be used in conjunction with others, they may have to be added manually (but with tags it could be easy). | The tags are managed by a program, it just has to be integrated with other tools (say, a tag-aware ''%%portsearch%%''). About packages that can be used in conjunction with others, they may have to be added manually (but with tags it could be easy). |
| |
| See [[http://www.tobez.org/port-tags/|Ports Tags]], [[http://debtags.alioth.debian.org/|Debian Debtags]] and [[/NewPortsCategories|NewPortsCategories]]. | See [[http://www.tobez.org/port-tags/|Ports Tags]], [[http://debtags.alioth.debian.org/|Debian Debtags]] and [[Ports/NewCategories]] |
| |
| === Architecture independent === | === Architecture independent === |
| ---- | ---- |
| |
| [[/CategoryTODO|CategoryTODO]] | {{tag>Ports Todo}} |
| |