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

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

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

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

> No, those problems will not arise as long as the maintainer tests the
> port before submitting an update. And the tested port of fixed version
> will be usable for a long time, unlike SCM-based one which may break
> every second.

That is true, but the only problem I see with snapshots is, if
maintainer is busy you can't do anything except maintaining your own local
port version on your box. And anyone using these SCM ports is the one
who knows things can go wrong often, and this is only for development
use.

>> > - 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.
>> 
>> So, this is the main reason which prevents this :( .

> I'd say it's the least significant reason. The main reasons are the
> first three which can be shortened as `the port will be unuseable and
> sometimes dangerous'.
> What's for automatic plist generation, I've given it some thought,
> and it seems like there could be a more or less reliable way after all.
> I'm currently doing some experiments.

Cool, would like to see the results of your experiments :).

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

> My opinion is that if you can diagnose the problem by yourself and come
> with a proper fix, you should submit it directly upstream. If you think
> that the problem is serious enough, you can send a port PR as well. If
> you cannot do it all by yourself though, you should submit a PR, in
> which case port's maintainer will take care of it.

I agree.

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

> It's not like your proposal is bad, ports instantaneously tracking
> upstream changes and not needing maintainers would really be cool,
> but unfortunately that's practically impossible.

Gentoo GNU/Linux which is a source-based GNU/Linux distribution has this
feature available, what is different in that is, that it uses a separate
root for recording the packing list port and optionally creating a
package.

Maybe we can introduce a hack in ports system like by adding some
variable like 'USES_DYNAMIC_PLIST=yes' in Makefile, which fill let the
port first installed with DESTDIR=/var/tmp/ports/${PORTNAME} and then a
packing list is generated and then finally whole tree is moved to
${PREFIX}, hmm...? What do you say ?

Thanks for you replies.

Ashish Shukla

P.S. do you've any ideas about when a discussion on this subject took
place on this list, hmm..?
-------------- 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/16aa3958/attachment.pgp