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

[Ashish Shukla आशीष शुक्ल]

Dmitry Marakasov writes:
> * 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.

These are the problems already expected with this but the only
suggestion is to have PRs filed if anything breaks during compilation
and investigate what caused it.

>> * 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

So, this is the main reason which prevents this :( .

>> * 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.

True, so either have all PRs should be submitted to FreeBSD PR system,
where maintainer will decide if its porting issue or upstream related
issue.

So with all the problems you mentioned above, I guess, I'll take my
proposal back :) .

Thanks for your comments.

-- 
Ashish Shukla
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20081209/2b961228/attachment.pgp