Date: Tue, 9 Dec 2008 17:30:52 +0300 From: Dmitry Marakasov <amdmi3@amdmi3.ru> To: Ashish Shukla =?utf-8?B?4KSG4KS24KWA4KS3IOCktuClgeCkleCljeCksg==?= <wahjava.ml@gmail.com> Cc: FreeBSD Ports Mailing List <freebsd-ports@freebsd.org> Subject: Re: [PROPOSAL] Ports using SCM repositories as source instead of distfiles Message-ID: <20081209143052.GA29817@hades.panopticon> In-Reply-To: <87fxkxjywk.fsf@chateau.d.lf> References: <87fxkxjywk.fsf@chateau.d.lf>
next in thread | previous in thread | raw e-mail | index | archive | help
* Ashish Shukla =E0=A4=86=E0=A4=B6=E0=A5=80=E0=A4=B7 =E0=A4=B6=E0=A5=81=E0=
=A4=95=E0=A5=8D=E0=A4=B2 (wahjava.ml@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 o=
f
> 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 th=
e
> 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 shoul=
d
> 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.
--=20
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081209143052.GA29817>