Bug 247430 - Linux ports install too much
Summary: Linux ports install too much
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-emulation (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-06-19 19:17 UTC by Mikhail Teterin
Modified: 2020-06-23 12:13 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mikhail Teterin freebsd_committer 2020-06-19 19:17:11 UTC
Most of the linux-c7-* ports download too much:
 a) both 64- and 32-bit RPMs;
 b) Source RPMs.

There may be a use case for a), but it should be possible to not install 32-bit Linux libraries on amd64. Indeed, it should, probably, be the default -- as it is on the actual RHEL7/CentOS7 systems already.

The b) seems outright bizarre -- why? GPL compliance? But everything with a linux-c7-* port on FreeBSD, that has sources publicly available, also has a native FreeBSD port, which downloads those sources (in a format more convenient than SRPM too).

Why waste so much space -- and bandwidth -- on these?
Comment 1 Tijl Coosemans freebsd_committer 2020-06-20 11:02:38 UTC
a) is because there are several 32-bit only Linux application ports.  Also, when I announced that I would remove the option to install a pure 32-bit linux_base on amd64 there was immediate response from users worried that their applications might break.  So I do think 32-bit support is actively used.  I use it myself now that I think about it.  I don't object to adding a knob for this somewhere, perhaps via bsd.default-versions.mk since this would be a tree-wide option and not a per-port option.  For end-users the ideal is probably to have separate packages though, which is a lot more work.

b) is something the Linux infrastructure ports have always done.  I think it is needed for strict compliance with the GPL, but even for non-GPL code it may be wise to have our own copy of the source code.  You never know why it might be useful.  Note that only package builders actually download the file.  Regular make doesn't.  Also note that an SRPM may contain patches that are not in the corresponding FreeBSD port.
Comment 2 Mikhail Teterin freebsd_committer 2020-06-22 22:07:04 UTC
> I don't object to adding a knob for this somewhere, perhaps via bsd.default-versions.mk since this would be a tree-wide option and not a per-port option.

Actually, it might still be per-port, but I agree, that that may be too much trouble.

Unless, maybe, our new FLAVORS mechanism can be utilized for it...

> even for non-GPL code it may be wise to have our own copy of the source code

I don't understand this part at all. Might be wise _for whom_? Have _where_?

> Note that only package builders actually download the file.  Regular make doesn't.

Yes, I just realized this... But why bother doing it -- and hosting the src.rpm on the distfile-mirrors?
Comment 3 Tijl Coosemans freebsd_committer 2020-06-23 12:13:38 UTC
(In reply to Mikhail Teterin from comment #2)
>> even for non-GPL code it may be wise to have our own copy of the source code
> I don't understand this part at all. Might be wise _for whom_? Have _where_?

Like I said: "you never know."  It's not a bad idea to make sure we have access to the source (even if upstream disappears).  For instance, it could be useful for debugging some problem.

The SRPMs are available under http://distcache.freebsd.org/ports-distfiles/centos/.