Multiple logical packages from a single source port

[Bryan Drewery]

Yes. The simplest guidance is that if the package changes, bump 
PORTREVISION. It seems bad to have 2 different packages of the same 
version installing files to different places.

Regards,
Bryan Drewery

Especially if it installs to a different place.

On 2014-02-06 14:08, Marcus von Appen wrote:
> Full quoting my initial message below for portmgr at .
> 
> The exp-run for the logical packages has finally been done and the 
> results
> are available at ports/185947. From what I could see by quickly 
> glancing over
> the ports, the impact is rather small and only a couple of ports need 
> to be
> fixed prior to commit.
> 
> If all things go well, we should be able to commit the change the next
> week.
> 
> portmgr@:
> Since the package layout (directories, files) of certain ports (those
> using USE_PYDISTUTILS) will be changed, I wonder, if we should also 
> bump the
> PORTREVISIONs for all of those.
> 
> Cheers
> Marcus
> 
> On, Thu Dec 19, 2013, Marcus von Appen wrote:
> 
>> Dear all,
>> 
>> now that we removed lang/python from bsd.python.mk, we need to enable
>> python ports to be built and installed for different python versions
>> without creating conflicts.
>> Looking at the TODO list, which I posted ages ago, this should be the
>> very last thing before the ports tree is able to support different
>> Python versions at the same time (the pkg tools are not, but that
>> another issue to deal with).
>> 
>> Many python ports install binaries (or scripts), docs, additional data
>> and other things besides their modules. While the latter, the modules,
>> already support different python versions out of the box (since they 
>> are
>> usually installed locally into a version-specific site-packages 
>> folder),
>> the first do not.
>> 
>> DATADIR, DOCDIR, WWWDIR and ETCDIR follow a <PREFIX>...<PORTNAME>
>> layout, and as such use the same directory for different python
>> versions. Binaries are often installed as defined by the upstream port
>> and as thus are not distinct when it comes to different python 
>> versions.
>> 
>> To work around this limitation and to enable ports as well as packages
>> to be installed for different python versions at the same time, the
>> current standard behaviour has to be tweaked.
>> 
>> I'd propose that standard directories, which currently use the 
>> PORTNAME
>> as identifier, shall carry a python version prefix. Binaries shall 
>> carry
>> a python version suffix, but shall be symlinked to their original 
>> name,
>> if the python version of the port matches the default python version
>> choice of the user.
>> 
>> What does that mean in practice? Assume, we have port devel/py-foo,
>> which, at this very moment, uses the following installation layout for
>> Python 2.7 (being the chosen default of the user):
>> 
>>   bin/foo
>>   lib/python2.7/site-packages/foo/__init__.py
>>   lib/python2.7/site-packages/foo/bar.py
>>   lib/python2.7/site-packages/foo/foofoo.py
>>   share/foo/bar/some.dat
>>   share/foo/arbitrary.dat
>>   share/doc/foo/README
>> 
>> In a prefixed ports world, the installation layout would be:
>> 
>>   bin/foo-py27
>>   bin/foo [links to]-> bin/foo-py27
>>   lib/python2.7/site-packages/foo/__init__.py
>>   lib/python2.7/site-packages/foo/bar.py
>>   lib/python2.7/site-packages/foo/foofoo.py
>>   share/py27-foo/bar/some.dat
>>   share/py27-foo/arbitrary.dat
>>   share/doc/py27-foo/README
>> 
>> If the user chooses to install devel/py-foo for a non-default python 
>> version
>> 3.3, the installation layout would be:
>> 
>>   bin/foo-py33
>>   lib/python3.3/site-packages/foo/__init__.py
>>   lib/python3.3/site-packages/foo/bar.py
>>   lib/python3.3/site-packages/foo/foofoo.py
>>   share/py33-foo/bar/some.dat
>>   share/py33-foo/arbitrary.dat
>>   share/doc/py33-foo/README
>> 
>> If the user would make Python 3.3 the default version and rebuild and
>> reinstall the port for 2.7 and 3.3, a symlink bin/foo --> bin/foo-py33
>> would appear instead of bin/foo --> foo-py27.
>> 
>> Certainly docs, data and other shared content would duplicate, but 
>> this
>> is safer, easier to maintain and less error-prone than to use shared
>> directories and lots of conditional magic in the installation and
>> deinstallation logic.
>> 
>> I created a POC as USES, named uniquefiles.mk, which can be used by
>> nearly every port (even non-python ones). For USE_PYDISTUTILS,
>> it would be implicitly used, other ports, e.g. autotools-based ones
>> installing python modules, would need to pull in the python specific
>> paramters via UNIQUE_PYTHON_FILES=yes.
>> 
>> Q: Do I have to touch the plists to enable support for it?
>> 
>>    No. The port logic will do that for you. You must not add a
>>    prefixed or suffixed binary name, though, but the original name
>>    only. In short, you MUST NOT add things like
>> 
>>      bin/foo-py27 or
>>      bin/foo-py32 or
>>      sbin/foo-py33
>>      ...
>> 
>>    if the upstream package does not create those files (which is
>>    unlikely).
>> 
>> Q: So nothing to be done for me?
>> 
>>    Right. Just watch your plists on updating.
>> 
>> Q: UNIQUE_PYTHON_FILES?
>> 
>>    Yes. If you are maintaining a python port, which does not use 
>> distutils (no
>>    USE_PYDISTUTILS=... in the Makefile), UNIQUE_PYTHON_FILES is what 
>> you want.
>>    Ports using USE_PYDISTUTILS will implicitly configure everything, 
>> so that
>>    DOCDIR, DATADIR, ... and binaries will be properly prefixed and 
>> suffixed.
>>    Your python port however does not use USE_PYDISTUTILS, so you can 
>> help
>>    yourself using UNIQUE_PYTHON_FILES=yes.
>> 
>> Q: Can I use it for my own port? It does not use python, though...
>> 
>>    Of course. uniquefiles.mk is a USES, thus each and every port can 
>> utilise
>>    it. Please refer to its inline comments for further details about 
>> how to
>>    configure and use it.
>> 
>> A patch for the current ports tree can be found at
>> http://people.freebsd.org/~mva/python_unique_ports.diff
>> 
>> If you just want to try out the uniquefiles feature, you can find a
>> separate diff at
>> http://people.freebsd.org/~mva/uniquefiles.diff
>> 
>> Readers are encouraged to give those patches a try in an own jail
>> :-). So far, I only tested them briefly, but will do more tests the 
>> next
>> days.
>> 
>> Cheers
>> Marcus

-- 
Regards,
Bryan Drewery