[PROPOSAL] Ports using SCM repositories as source instead of distfiles

[Dmitry Marakasov]

* Ashish Shukla आशीष शुक्ल (wahjava.ml at gmail.com) wrote:

> I'm to proposing an enhancement to existing FreeBSD ports system. I
> think it'll be great if ports can use SCM (source code management)
> repositories like CVS, Subversion, Git, etc. as their sources instead of
> distfiles. Following are some of the {dis,}advantages of this approach:

This was discussed before. The summary: this won't work with ports.
Reasons:

- No way to track port updates.

- No way to save distfile. Source will be redownloaded on every rebuild.

- Security. No one can guarantee that malicious source won't be cheched
  into the repository at some random time. Fixed versions can be at
  least minimally checked and it is possible to not update the port to
  new version if it contains problems and/or tell users to not install
  version XXX. Impossible for SCM-based ports.

> * ATM, development versions of ports are packaged as snapshots, and
>   maintainer has to keep updating ports snapshots. And sometimes,
>   it is not possible for maintainer (due to lack of time and other
>   issues) to update snapshots timely. So going proposed way can ease the
>   work for them, and beneficial for users who are interested in latest
>   bits.

- _Much_ more (instead of less) work for maintainer, as he won't be able
  to test the port before committing it and will have to deal with all
  the problems post factum, under extra pressure.

- Actually, any SCM-based port will become broken rather soon than
  later with no ability to prevent it.
  The port uses patches? Due to mutable source it'll become broken.
  Any structural change upstream? Port broken. Changed build system?
  Broken. Changed paths? Broken. Changed depends? Broken. Changed
  options/configure args? Broken. Etc.

> * I've not played (or worked) with dynamic packaging lists on FreeBSD,
>   so I'm not sure if it is possible to properly track all installed
>   files dynamically, e.g. if a new commit in the upstream causes 3 new
>   files to be installed, then is it possible for FreeBSD ports
>   management system to include those 3 files also in the packing list,
>   in the next installation of the port, hmm...?

- Generic dynamic plist generation is impossible unless the port
  is installed into some clean chrooted environemnt (for example,
  using DESTDIR). The latter, however takes extra space and time,
  as you need the whole system and all dependent packages installed
  there as well. Simply building the port will become more more like
  producing package in a tinderbox:
  - unpack the system image
  - mount all required filesystems - devfs, ports, distfiles, packages
  - install all required packages
  - take list of all files in the chroot
  - chroot and install the port
  - take list of all files in the chroot, compare with previous one and
    make a plist out of it
  - umount and remove everything
  - now you have package and may install in normally

> * As far as PR related to such ports are concerned I think one should
>   directly submit them to the upstream rather than maintainer, unless
>   that PR has anything to do with its packaging, in which case it should
>   be submitted to FreeBSD PR system.

Sometimes it's hard to tell whether the problem is FreeBSD-specific.
Also, upstream is unlikely to have FreeBSD box for testing, so again
it'll be more work for maintainer.

-- 
Dmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D
amdmi3 at amdmi3.ru  ..:  jabber: amdmi3 at jabber.ru    http://www.amdmi3.ru