| Both sides previous revision Previous revision Next revision | Previous revision |
| ports:todo [2008/03/24 18:01] – Add more items (need reorganization) AlejandroPulver | ports:todo [2023/01/29 14:08] (current) – man.freebsd.org GrahamPerrin |
|---|
| | ([[/MarkLinimon|MarkLinimon]] note: this is [[/AlejandroPulver|AlejandroPulver]]'s list of his priorities. As of 20110610, it has not been updated for a while, and parts are now obsoleted by current events.) |
| | |
| ====== Ports TODO ====== | ====== Ports TODO ====== |
| |
| The sub-projects/items are organized so they are grouped under related upper level concepts/functionalities. Recently, the contents were organized in ordered //stages//, to represent a coherent schedule (step-by-step) where features can be implemented progressively and with less breakage. | The sub-projects/items are organized so they are grouped under related upper level concepts/functionalities. Recently, the contents were organized in ordered //stages//, to represent a coherent schedule (step-by-step) where features can be implemented progressively and with less breakage. |
| |
| If editing this page (a clarification never hurts), please try to keep it on topic (for example, requesting a new portupgrade option would better fit into ["portupgrade"]), include references if any, and let me know about changes. For style and markup, corrections are welcome (this is my first wiki page). | If editing this page (a clarification never hurts), please try to keep it on topic (for example, requesting a new portupgrade option would better fit into [[/portupgrade]]), include references if any, and let me know about changes. For style and markup, corrections are welcome (this is my first wiki page). |
| |
| **Table of Contents** | **Table of Contents** |
| [[/TableOfContents(4)|TableOfContents(4)]] | |
| |
| ===== Stage 1: Current status ===== | ===== Stage 1: Current status ===== |
| ^ Feature/subject ^ pkgsrc ^ (%%FreeBSD%%) ports ^ (%%OpenBSD%%) ports ^ mports ^ Portage ^ dpkg/rpm + apt ^ | ^ Feature/subject ^ pkgsrc ^ (%%FreeBSD%%) ports ^ (%%OpenBSD%%) ports ^ mports ^ Portage ^ dpkg/rpm + apt ^ |
| | Used by OSes | %%NetBSD%%, %%DragonflyBSD%% | %%FreeBSD%% | %%OpenBSD%% | %%MidnightBSD%% | Gentoo, Sabayon | Ubuntu, Debian, Fedora, Redhat | | | Used by OSes | %%NetBSD%%, %%DragonflyBSD%% | %%FreeBSD%% | %%OpenBSD%% | %%MidnightBSD%% | Gentoo, Sabayon | Ubuntu, Debian, Fedora, Redhat | |
| | Ports | ✔ | ✔ | ✔ | ✔ | ✔ | ✘ [[/FootNote(There are source packages, which contain both the full source code of the program and local patches, and are manually compiled and uploaded by the maintainer.)|FootNote(There are source packages, which contain both the full source code of the program and local patches, and are manually compiled and uploaded by the maintainer.)]] | | | Ports | ✔ | ✔ | ✔ | ✔ | ✔ | ✘ ((There are source packages, which contain both the full source code of the program and local patches, and are manually compiled and uploaded by the maintainer.)) | |
| | Packages | ✔ | ✔ | ✔ | ✔ | {o} [[FootNote(A Gentoo derivate called Sabayon is developing a tool called _http_//en.wikipedia.org/wiki/Sabayon_Linux#Features entropy], which uses `binmerge` for binary packages.)|FootNote(A Gentoo derivate called Sabayon is developing a tool called [http://en.wikipedia.org/wiki/Sabayon_Linux]] | ✔ | | | Packages | ✔ | ✔ | ✔ | ✔ | {o} ((A Gentoo derivate called Sabayon is developing a tool called [http://en.wikipedia.org/wiki/Sabayon_Linux#Features entropy], which uses ''%%binmerge%%'' for binary packages.)) | ✔ | |
| | Primary focus (src/bin) | ? | src | bin | ? | src | bin | | | Primary focus (src/bin) | ? | src | bin | ? | src | bin | |
| | Packages and ports integration | ? | {o} [[/FootNote(Some features are only supported by ports, like versioned dependencies. Also ports install directly, without generating packages.)|FootNote(Some features are only supported by ports, like versioned dependencies. Also ports install directly, without generating packages.)]] | ✔ [[/FootNote(Ports create the package and then uses the package tools to install.)|FootNote(Ports create the package and then uses the package tools to install.)]] | ? | ? | ✘ | | | Packages and ports integration | ? | {o} ((Some features are only supported by ports, like versioned dependencies. Also ports install directly, without generating packages.)) | ✔ ((Ports create the package and then uses the package tools to install.)) | ? | ? | ✘ | |
| | Many packages out of same port | ? | {o} [[/FootNote(Shared code in one port, called by a slave port which only defines the required options (requires a directory with a `Makefile` for each package).)|FootNote(Shared code in one port, called by a slave port which only defines the required options (requires a directory with a `Makefile` for each package).)]] | ✔ | ? | ✘ | ? | | | Many packages out of same port | ? | {o} ((Shared code in one port, called by a slave port which only defines the required options (requires a directory with a ''%%Makefile%%'' for each package).)) | ✔ | ? | ✘ | ? | |
| | Apps divided in many packages | ✘ | ✘ | ✘ | ✘ | ✘ | ✔ [[/FootNote(Packages are split in `-doc`, `-dev`, `-common`, `-data`, etc. The good point is that packages which don't depend on the architecture are built only once, runtime dependencies don't require headers, and documentation is optional. However to build anything you need all the `-dev` versions.)|FootNote(Packages are split in `-doc`, `-dev`, `-common`, `-data`, etc. The good point is that packages which don't depend on the architecture are built only once, runtime dependencies don't require headers, and documentation is optional. However to build anything you need all the `-dev` versions.)]] | | | Apps divided in many packages | ✘ | ✘ | ✘ | ✘ | ✘ | ✔ ((Packages are split in ''%%-doc%%'', ''%%-dev%%'', ''%%-common%%'', ''%%-data%%'', etc. The good point is that packages which don't depend on the architecture are built only once, runtime dependencies don't require headers, and documentation is optional. However to build anything you need all the ''%%-dev%%'' versions.)) | |
| | Self-contained packages | ? | ? | ? | ? | ? | ? | | | Self-contained packages | ? | ? | ? | ? | ? | ? | |
| | Building in a clean environment | ✔ | {o} (tinderbox/portbuild) | ✔ | ✔ (recently) | ? | ✔ | | | Building in a clean environment | ✔ | {o} (tinderbox/portbuild) | ✔ | ✔ (recently) | ? | ✔ | |
| | Initial configuration and integration of apps | ? | ? | ? | ? | ? | ? | | | Initial configuration and integration of apps | ? | ? | ? | ? | ? | ? | |
| | License framework (info/agreement) | ? | ? | ? | ? | ? | ? | | | License framework (info/agreement) | ? | ? | ? | ? | ? | ? | |
| |
| [[/FootNote()|FootNote()]] | |
| |
| **References** | **References** |
| ==== References ==== | ==== References ==== |
| |
| * [http://www.freebsd.org/cgi/query-pr-summary.cgi?responsible=portmgr Infrastructure PRs] usually contain patches, see also closed ones which were not committed. | * [[http://www.freebsd.org/cgi/query-pr-summary.cgi?responsible=portmgr|Infrastructure PRs]] usually contain patches, see also closed ones which were not committed. |
| * [http://en.wikipedia.org/wiki/Comparison_of_Linux_distributions#Features Number of packages] of Linux distributions (note that Debian and Ubuntu split most of them in components and offer many built with different options). | * [[http://en.wikipedia.org/wiki/Comparison_of_Linux_distributions#Features|Number of packages]] of Linux distributions (note that Debian and Ubuntu split most of them in components and offer many built with different options). |
| * 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"] (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]]. |
| |
| ===== Stage 2: Clean up infrastructure ===== | ===== Stage 2: Clean up infrastructure ===== |
| ==== Clean up USE and WITH variables ==== | ==== Clean up USE and WITH variables ==== |
| |
| See [http://www.freebsd.org/projects/ideas/#p-ports-cleanup-use Project Ideas entry]. | See [[http://www.freebsd.org/projects/ideas/#p-ports-cleanup-use|Project Ideas entry]]. |
| |
| ==== Reorganization of ports/Mk ==== | ==== Reorganization of ports/Mk ==== |
| Recently, ''%%bsd.port.mk%%'' was split into different files, which still provide the "core" functionality. These are mixed with "plugin" files (i.e. ''%%bsd.apache.mk%%''), still required for the system of course, but in an //upper// layer. | Recently, ''%%bsd.port.mk%%'' was split into different files, which still provide the "core" functionality. These are mixed with "plugin" files (i.e. ''%%bsd.apache.mk%%''), still required for the system of course, but in an //upper// layer. |
| |
| It would be good for purposes of organizations to move them into a sub-directory (like ''%%plugins%%''). This way modification policies to them could be more relaxed, being able to affect only a subset of ports, and maintained more efficiently. For example, ''%%bsd.gecho.mk%%'' which resides in ''%%www/mozilla%%'' could be moved there. | It would be good for purposes of organizations to move them into a sub-directory (like ''%%plugins%%''). This way modification policies to them could be more relaxed, being able to affect only a subset of ports, and maintained more efficiently. For example, ''%%bsd.mesalib.mk%%'' which resides in ''%%graphics/libGL%%'' could be moved there. |
| |
| === Internal API for bsd.*.mk files === | === Internal API for bsd.*.mk files === |
| |
| === Removing ${PORTSDIR} from dependencies === | === Removing ${PORTSDIR} from dependencies === |
| | |
| | :!: [[/PavLucistnik|PavLucistnik]] has suggested that this is unneccessary. |
| |
| Every dependency has ''%%${PORTSDIR}%%'' before the port directory. Removing this requirement would be the first step towards some kind of virtual dependencies (and more over abstract ports, see related item). | Every dependency has ''%%${PORTSDIR}%%'' before the port directory. Removing this requirement would be the first step towards some kind of virtual dependencies (and more over abstract ports, see related item). |
| |
| :idea: //Implementation:// vert few lines of make code in ''%%bsd.port.mk%%'' to add ''%%${PORTSDIR}%%'' if not present (for backwards compatibility) when needed. %%OpenBSD%% has already done this. | :idea: //Implementation:// very few lines of make code in ''%%bsd.port.mk%%'' to add ''%%${PORTSDIR}%%'' if not present (for backwards compatibility) when needed. %%OpenBSD%% has already done this. |
| |
| === 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. |
| |
| === Plugin and addon ports === | === Plugin and addon ports === |
| | |
| | :!: Rework (evaluate the real need in the existing ports, and think of a simple non-breaking implementation if needed) |
| |
| If you have one port of an application and many ports for plugins for that application, the latter must depend on the former, that is unable to depend on its plugins (i.e. offering them through ''%%OPTIONS%%'') to avoid a circular dependency. | If you have one port of an application and many ports for plugins for that application, the latter must depend on the former, that is unable to depend on its plugins (i.e. offering them through ''%%OPTIONS%%'') to avoid a circular dependency. |
| It would also be useful to be able to mention related applications that can be used in conjunction with other, like Debian's //suggested// and //recommended// optional dependencies. | It would also be useful to be able to mention related applications that can be used in conjunction with other, like Debian's //suggested// and //recommended// optional dependencies. |
| |
| === Cache dependencies for package registration === | === Explicit and implicit dependencies === |
| |
| :!: Find original discussion (ports@ archive) and link, check current approach. | Currently both implicit and explicit dependencies are registered (i.e. port A depends on B which depends on C, when installing A appears as requiring both B and C). |
| |
| Use the recorded dependencies (files in ''%%/var/db/pkg%%'') for faster port registration at installation (instead of recursive scan). | The problem is that most if not all ports rely on implicit dependencies to work (i.e. they don't list all actual explicit dependencies as such). |
| |
| === Register explicit dependencies only === | After implementing ''%%OPTIONS%%'' support in dependencies, some (only a part) of these problems could be solved (i.e. if really needed, A would depend on B built with C support). |
| | |
| :!: Is this right? Find related discussions (ports@ archive) and link. | |
| | |
| Currently both implicit and explicit dependencies are registered (i.e. port A depends on B which depends on C, when installing A appears as requiring both B and C). | |
| |
| Maybe after implementing ''%%OPTIONS%%'' support in dependencies, the need of doing this could be removed (i.e. if really needed, A would depend on B built with C support). | The rest (most) of the issues would need basically changing almost every port. But the majority of these dependencies are to libraries and ''%%ldconfig%%'' could help a lot (most run only dependencies are listed as ''%%RUN_DEPENDS%%''). |
| |
| At least explicit and implicit dependencies could be recorded separetely, either in different files or in form of a tree/graph so they can be managed in a better way. | At least explicit and implicit dependencies could be recorded separetely, either in different files or in form of a tree/graph so they can be managed in a better way, and these problems could be tracked progressively. |
| |
| ==== Fetch improvements ==== | ==== Fetch improvements ==== |
| === More protocols === | === More protocols === |
| |
| See ["Metalink"], which also mentions P2P. | See [[/Metalink]], which also mentions P2P. |
| |
| Also implementing support for ''%%.md5%%'', ''%%.gpg%%'', and other checksums residing next to the distfile on the official site would be a good idea. | Also implementing support for ''%%.md5%%'', ''%%.gpg%%'', and other checksums residing next to the distfile on the official site would be a good idea. |
| === Calculate fastest MASTER_SITES === | === Calculate fastest MASTER_SITES === |
| |
| Add a target to calculate speeds of sites in ''%%bsd.sites.mk%%'', and cache them (similar to ''%%fastest_cvsup%%''). | There is a port [[http://www.freshports.org/ports-mgmt/fastest_sites|ports-mgmt/fastest_sites]] that finds the fastest mirror for every mirror list in ''%%bsd.sites.mk%%'', with output suitable for inclusion in ''%%make.conf%%''. |
| | |
| | There is no equivalent for individual ports which define all ''%%MASTER_SITES%%'', but it's not needed. What could be done is revisit each port to ensure they use ''%%bsd.sites.mk%%'' entries whenever possible, and add more if applicable. |
| |
| ==== Desktop ==== | ==== Desktop ==== |
| === Synchronizing menus === | === Synchronizing menus === |
| |
| A tool like Debian's [http://www.handhelds.org/~nelson/menu/ menu] (and [http://www.debian.org/doc/packaging-manuals/menu-policy/ch2.html#s2.1 structure]) should be provided to keep different desktop and window manager menus in sync. | A tool like Debian's [[http://www.handhelds.org/~nelson/menu/|menu]] (and [[http://www.debian.org/doc/packaging-manuals/menu-policy/ch2.html#s2.1|structure]]) should be provided to keep different desktop and window manager menus in sync. |
| |
| See [http://www.gentoo.org/proj/en/glep/glep-0016.html Gentoo GLEP]. | See [[http://www.gentoo.org/proj/en/glep/glep-0016.html|Gentoo GLEP]]. |
| |
| === Registering X session types === | === Registering X session types === |
| |
| ==== More automatizations ==== | ==== More automatizations ==== |
| |
| === Automatic registering of UID and GID === | |
| |
| See [http://www.freebsd.org/projects/ideas/#p-ports-uid Project Ideas entry]. | |
| |
| :idea: //Implementation:// for packages, as at this stage they aren't supposed to be modified, a shell script could be added to it and called at installation/removal (''%%@exec%%'' and ''%%@unexec%%''). | |
| |
| === Configuration files === | |
| |
| The installation/removal of configuration files is currently done from the Makefile and pkg-plist, in both cases with manual commands. A simple set of variables could help both keeping them in the same place, and allow further additions. For now, they would do the same, but in an automated way. | |
| |
| ^ Variable ^ Description ^ Example ^ | |
| | ''%%CFG_DIR%%'' | Directory where configuration files are installed | ''%%${ETCDIR}%%'' | | |
| | ''%%CFG_SUFFIX%%'' | Sample suffix of configuration files | ''%%-dist%%'', ''%%.sample%%'' | | |
| | ''%%CFG_FILES%%'' | List of configuration files | ''%%foo.conf%%'', ''%%bar.cfg%%'' | | |
| |
| Then the port only has to be sure the application installs the sample files. | |
| |
| :idea: //Implementation:// some lines of make code in ''%%bsd.port.mk%%'' to add a ''%%PLIST_FILES%%'' entry and ''%%@exec%%''/''%%@unexec%%'' directives for each file. The order of the directives is critcal, Implementations have rotted gnats. | |
| |
| === Managing entries in common files === | === Managing entries in common files === |
| |
| For example, lines in ''%%/etc/shells%%'', PHP extensions list, and other //required// places (i.e. not ''%%rc.conf%%'', for that see post-install tool). It needs to support the basic methods of doing this (i.e. plain entries, .ini files, etc). | For example, lines in ''%%/etc/shells%%'', PHP extensions list, X session types, and other //required// places (i.e. not ''%%rc.conf%%'', for that see post-install tool). It needs to support the basic methods of doing this (i.e. plain entries, .ini files, etc). |
| |
| See current ports in shells category, others that append to ''%%/etc/sysctl.conf%%'', etc. for ideas. | See current ports in shells category, others that append to ''%%/etc/sysctl.conf%%'', etc. for ideas. |
| === Collect the pkg-message output === | === Collect the pkg-message output === |
| |
| See [http://www.freebsd.org/projects/ideas/#p-ports-collect-messages Project Ideas entry] and [http://www.mail-archive.com/freebsd-ports@freebsd.org/msg13275.html possible implementation]. | See [[http://www.freebsd.org/projects/ideas/#p-ports-collect-messages|Project Ideas entry]] and [[http://www.mail-archive.com/freebsd-ports@freebsd.org/msg13275.html|possible implementation]]. |
| |
| Instead of just printing the contents of all pkg-message files at the end, it could be made configurable to only indicate the installed packages that have one. This could also be left to the post-installation tool. | Instead of just printing the contents of all pkg-message files at the end, it could be made configurable to only indicate the installed packages that have one. This could also be left to the post-installation tool. |
| Of course the clear adventage of this comes when automating (i.e. integrating with GNATS bot). | Of course the clear adventage of this comes when automating (i.e. integrating with GNATS bot). |
| |
| See ["[[/MaintainerNotes|MaintainerNotes]]"]. | See [[/MaintainerNotes]]. |
| |
| === License === | === License === |
| |
| 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"]. | |
| |
| :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?). |
| ==== COMPAT_43TTY ==== | ==== COMPAT_43TTY ==== |
| |
| See [http://www.freebsd.org/projects/ideas/#p-ports-comp43tty Project Ideas entry]. | See [[http://www.freebsd.org/projects/ideas/#p-ports-comp43tty|Project Ideas entry]]. |
| | |
| | Most of this has already been done. |
| |
| ==== portbuilt/tinderbox chroot "patching" ==== | ==== portbuilt/tinderbox chroot "patching" ==== |
| |
| :!: Is this correct? Please let me know otherwise. | :!: Pav says it doesn't worth, as it takes seconds, and the prioritized areas are others. Ask Joe? |
| |
| 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: |
| - Integrate with ''%%KNOBS%%'', use common names and allow "global" settings in /etc/make.conf. | - Integrate with ''%%KNOBS%%'', use common names and allow "global" settings in /etc/make.conf. |
| - Provide a "fake port" to configure the system itself (i.e. changing ''%%PREFIX%%''/''%%DESTDIR%%'', as it would be simply a //path// variable), eliminating the need of manualy tweaking /etc/make.conf (i.e. setting default Apache, Tcl/Tk, wxWidgets, etc). The implementation should also provide an API to be used internally for this case. | - Provide a "fake port" to configure the system itself (i.e. changing ''%%PREFIX%%''/''%%DESTDIR%%'', as it would be simply a //path// variable), eliminating the need of manualy tweaking /etc/make.conf (i.e. setting default Apache, Tcl/Tk, wxWidgets, etc). The implementation should also provide an API to be used internally for this case. |
| - As a backwards feature similar to the graphical extension, allow it to behave as old knobs (i.e. either show text or nothing, as ''%%BATCH%%'' but still respect user settings). It would completely replace knobs so it should conform everyone (see [http://www.freshports.org/editors/vim/ editors/vim] for example) who currently has a good reason to avoid ''%%OPTIONS%%''. So it should have a configurable behavior, possibly asking people who don't like current ''%%BATCH%%'' mode (and the implementation in general). | - As a backwards feature similar to the graphical extension, allow it to behave as old knobs (i.e. either show text or nothing, as ''%%BATCH%%'' but still respect user settings). It would completely replace knobs so it should conform everyone (see [[http://www.freshports.org/editors/vim/|editors/vim]] for example) who currently has a good reason to avoid ''%%OPTIONS%%''. So it should have a configurable behavior, possibly asking people who don't like current ''%%BATCH%%'' mode (and the implementation in general). |
| - A ''%%dialog%%'' with more features would be needed, or multiple calls otherwise (see ''%%dialog%%'' clones in ports). | - A ''%%dialog%%'' with more features would be needed, or multiple calls otherwise (see ''%%dialog%%'' clones in ports). |
| |
| ==== New policies ==== | ==== New policies ==== |
| |
| See %%MidnightBSD%%'s [http://www.midnightbsd.org/docs/mports/policy.html mports policies]. | See %%MidnightBSD%%'s [[http://www.midnightbsd.org/documentation/mports/policy.html|mports policies]]. |
| |
| === Consistency === | === Consistency === |
| === Integration of ports with corresponding built packages === | === Integration of ports with corresponding built packages === |
| |
| :?: By ["[[/ThierryThomas|ThierryThomas]]"]. | :?: By [[/ThierryThomas]]. |
| |
| One weakness of our packages system is the incoherences between the users' ports tree and the available packages: | One weakness of our packages system is the incoherences between the users' ports tree and the available packages: |
| |
| :idea: //Implementation:// roll a tarball as mentioned, add date support to ''%%portsnap%%'', make a list of available "package sets" with portstree or a reference to it, accessible by web and relevant tools. | :idea: //Implementation:// roll a tarball as mentioned, add date support to ''%%portsnap%%'', make a list of available "package sets" with portstree or a reference to it, accessible by web and relevant tools. |
| | |
| | Update ([[/UlfLilleengen|UlfLilleengen]]): |
| | Why can't we instead change the package building procedure to make sure the latest packages are always built? For instance, when a port is updated, a daemon watching the ports tree or a commit hook can trigger a port rebuild of the port in question, thus making sure that the package is always built from the latest port, and doesn't have to wait for a complete sweep over all the packages to complete. |
| |
| === Optionified packages === | === Optionified packages === |
| Darwinports/macports has a very nice idea: It names each package according to the version and options used to build it. When you install a package, it will try to find a pre-built binary and if that fails, it will download and compile from scratch. This allows the central repository to keep pre-built versions for the most popular packages (and it knows what those are because it can record the requests to the central repository) without limiting end users. In the ideal case, the central repository would automatically prioritize package builds so that the central package cluster utilized its limited CPU resources as efficiently as possible. | Darwinports/macports has a very nice idea: It names each package according to the version and options used to build it. When you install a package, it will try to find a pre-built binary and if that fails, it will download and compile from scratch. This allows the central repository to keep pre-built versions for the most popular packages (and it knows what those are because it can record the requests to the central repository) without limiting end users. In the ideal case, the central repository would automatically prioritize package builds so that the central package cluster utilized its limited CPU resources as efficiently as possible. |
| |
| === Fake installations === | === Fake builds === |
| |
| In %%OpenBSD%% ports install in a "fake" environment, then are packaged and finally (if doing so) installed to the system. This avoids duplicating installation code in the ports and packages. Recently %%MidnightBSD%%'s mports switched to this method (it's important since it was based in %%FreeBSD%% 6.1 beta so changes could be imported). | In %%OpenBSD%% ports install in a "fake" environment, then are packaged and finally (if doing so) installed to the system. This avoids duplicating installation code in the ports and packages. Recently %%MidnightBSD%%'s mports switched to this method (it's important since it was based in %%FreeBSD%% 6.1 beta so changes could be imported). |
| |
| See [http://www.midnightbsd.org/docs/mports/index.html mports]. | See [[http://www.midnightbsd.org/docs/mports/index.html|mports]]. |
| |
| === Symlinked installations === | === Symlinked builds === |
| |
| This is %%NetBSD%%'s approach, which consists in symlinkng required dependencies to the work directory and building from there (translating "-I/usr/local/include" and such by a compiler wrapper). | This is %%NetBSD%%'s approach, which consists in symlinkng required dependencies to the work directory and building from there (translating "-I/usr/local/include" and such by a compiler wrapper). |
| === Rewrite pkg tools === | === Rewrite pkg tools === |
| |
| See Project Ideas: [http://www.freebsd.org/projects/ideas/#p-ports-db hashed .db] and [http://www.freebsd.org/projects/ideas/#p-ports-pkgtools improvements]. | See Project Ideas: [[http://www.freebsd.org/projects/ideas/#p-ports-db|hashed .db]] and [[http://www.freebsd.org/projects/ideas/#p-ports-pkgtools|improvements]]. |
| |
| Also, ''%%pkg_create -b%%'' does not archive ''%%pkg-message%%''. | Also, ''%%pkg_create -b%%'' does not archive ''%%pkg-message%%''. |
| === Write an upgrading tool === | === Write an upgrading tool === |
| |
| See [http://www.freebsd.org/projects/ideas/#p-ports-upgrade Project Ideas entry]. | See [[http://www.freebsd.org/projects/ideas/#p-ports-upgrade|Project Ideas entry]]. |
| | |
| | === Mixing data from ports and executables from packages === |
| | |
| | An intermediate approach from Debian (a package for data, docs, bin, etc) and Gentoo (everything is built) would be having ports for the data of large applications (the ones likely to have NO_PACKAGE because of the size) split from the binary parts where the package is generated. Then when installing the data is fetch from official mirrors and binary package downloaded from repository. |
| |
| ==== pkg_add extracting directly to destination ==== | ==== pkg_add extracting directly to destination ==== |
| ==== Parallelization ==== | ==== Parallelization ==== |
| |
| See [http://www.freebsd.org/projects/ideas/#p-ports-parallel Project Ideas entry]. | See [[http://www.freebsd.org/projects/ideas/#p-ports-parallel|Project Ideas entry]]. |
| |
| === Package tools and locking === | === Package tools and locking === |
| === Multiple ports at the same time === | === Multiple ports at the same time === |
| |
| See [http://uyota.asablo.jp/blog/2007/07/26/1681765 ports+]. | See [[http://uyota.asablo.jp/blog/2007/07/26/1681765|ports+]]. |
| |
| IMHO it should also allow different concurrent ''%%make%%'' operations (the ''%%-jX%%'' is for illustration purposes but should be used internally, controlled from a variable): | IMHO it should also allow different concurrent ''%%make%%'' operations (the ''%%-jX%%'' is for illustration purposes but should be used internally, controlled from a variable): |
| In addition, it should support for example fetching a port while another is building. | In addition, it should support for example fetching a port while another is building. |
| |
| === Multiple processes in one port === | === Multiple processes in one port (make -jN) === |
| |
| Needs testing which ports work and which don't, but some would present random failures so a test should be kept running on a "mostly working" tree for some time. The addition of ''%%-jX%%'' to ''%%MAKE_ARGS%%'' is mentioned but other systems are omitted (like ''%%scons%%'', ''%%jam%%'', ''%%cmake%%''), which are more likely to be free of these problems. | Needs testing which ports work and which don't, but some would present random failures so a test should be kept running on a "mostly working" tree for some time. The addition of ''%%-jX%%'' to ''%%MAKE_ARGS%%'' is mentioned but other systems are omitted (like ''%%scons%%'', ''%%jam%%'', ''%%cmake%%''), which are more likely to be free of these problems. |
| |
| //Implementation:// some lines of make code in ''%%bsd.port.mk%%'' to check for user setting, available CPU and if port can be built with many jobs (whitelist/blacklist file, or per-port variable). Support for other build systems (''%%bsd.scons.mk%%'', upcoming ''%%bsd.cmake.mk%%'', etc). The rest is filling the lists. | //Implementation:// some lines of make code in ''%%bsd.port.mk%%'' to check for user setting, available CPU and if port can be built with many jobs (whitelist/blacklist file, or per-port variable). Support for other build systems (''%%bsd.scons.mk%%'', upcoming ''%%bsd.cmake.mk%%'', etc). The rest is filling the lists. |
| | |
| | We have two PR's to achieve 'make -jN' for building a port. The simpler one is ports/122120 and the more complicated one is ports/113132. The two may be combinable. |
| |
| ==== Cross-platform support ==== | ==== Cross-platform support ==== |
| === 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 ==== |
| * Other information (for example, how to upgrade Gnome to a newer version). | * Other information (for example, how to upgrade Gnome to a newer version). |
| |
| See: there is a parser that only shows corresponding entries [http://www.mail-archive.com/freebsd-ports@freebsd.org/msg10695.html here]. | See: there is a parser that only shows corresponding entries [[http://www.mail-archive.com/freebsd-ports@freebsd.org/msg10695.html|here]]. |
| |
| === Transactional updates === | === Transactional updates === |
| |
| - 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. |
| - Keep track of any ports leftovers, including configuration files and user placed files/dirs. Ports that have ''%%@unexec rm ... || echo "Please remove ..."%%'' could delegate that action to this tool (and others that don't should too). | - Keep track of any ports leftovers, including configuration files and user placed files/dirs. Ports that have ''%%@unexec rm ... || echo "Please remove ..."%%'' could delegate that action to this tool (and others that don't should too). |
| There are many ports that only wrap another subsystem (usually assisted by a ''%%bsd.*.mk%%'' component), like: | There are many ports that only wrap another subsystem (usually assisted by a ''%%bsd.*.mk%%'' component), like: |
| |
| * Linux packages | * Linux packages (:!: present before but removed, ask for the actual reasons; rpm-pkg2port is in progress) |
| * Perl CPAN | * Perl CPAN |
| * PHP Pear/Pecl | * PHP Pear/Pecl |
| 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 === |
| Conflicts are an ugly problem. Many systems require that packages tell which other packages they conflict with. This is impossible to maintain in the long run. Better to detect resource conflicts automatically. For example, filenames can conflict and since every package has a manifest, we can detect that automatically. If each package advertises port usage, for example, then the package system can also detect port conflicts automatically. (Of course, port usage then needs to be a configuration option: If the package system tells you that you can't install Postfix because Sendmail is already using port 25, you need to have the option of either removing Sendmail or installing Postfix on a different port.) | Conflicts are an ugly problem. Many systems require that packages tell which other packages they conflict with. This is impossible to maintain in the long run. Better to detect resource conflicts automatically. For example, filenames can conflict and since every package has a manifest, we can detect that automatically. If each package advertises port usage, for example, then the package system can also detect port conflicts automatically. (Of course, port usage then needs to be a configuration option: If the package system tells you that you can't install Postfix because Sendmail is already using port 25, you need to have the option of either removing Sendmail or installing Postfix on a different port.) |
| |
| -- [[/AlejandroPulver|AlejandroPulver]] [[/DateTime(2008-02-22T13_51_06Z)|DateTime(2008-02-22T13:51:06Z)]] | ==== Integration with the base system ==== |
| | |
| | Being able to integrate ports in the base system would be a very good thing, for example, for installing modified/development/experimental versions of applications (such as dtrace or base system projects). Also for updating, providing patched kernels, etc. |
| | |
| | -- [[/AlejandroPulver|AlejandroPulver]] 2008-02-22 13:51:06 UTC |
| | |
| | ---- |
| | |
| | {{tag>Ports Todo}} |
| |