Re: [OSR] Ports-like package management system

[Sylvain Le Gall <sylvain@le-gall.net>]

On 30-01-2008, Berke Durak <berke.durak@exalead.com> wrote:
> Sylvain Le Gall a écrit :
>> On 30-01-2008, Berke Durak <berke.durak@exalead.com> wrote:
>>> When you develop a program P you will have use programs P_{i1}, P_{i2}, 
>>> ... and thus have checkouts of repositories S_{i1}, S_{i2}, and so on. 
>>> If you find a bug in P_{i1} you can directly edit the checked out 
>>> version, recompile everything automatically by launching ocaml in P's 
>>> directory and thus debug P_{i1}.  You can then locally commit your 
>>> changes to P_{i1} and then easily push the patch or send the diff to the 
>>> upstream author.
>>>
>> 
>> Send a patch to author of P_{i1}. This is the easiest way. 
>> 
>> <hint>
>> diff -Nurd  P_{i1} P_{i1}.new
>> </hint>
>
> So you need to get a separate copy of P_{i1}, unpack it, and run a diff 
> by hand...  And what will happen during the process of developing the 
> patch?  You will be working on your patch without version control 
> system.  Which is very uncomfortable, especially as you will be working 
> on unfamiliar code - you will make mistakes, erase or modify important 
> stuff, won't be able to easily rollback, branch or review your changes.
> You will have to play around with tar, diff, patch and merge by hand, 
> make mistakes and create a mess.  Any VCS can handle all these tasks easily.
>
> Unless your correction is very minor, you will have to either (a) import 
> the project into your own favorite VCS, losing history and create a 
> short-lived repository or be forced to track all future changes by hand; 
> or (b) checkout the sources using the VCS the authors use - but then 
> we're back at case one: you will have to potentially have all the 
> version control systems used by all the software components you may want 
> to contribute to, and also learn how to use them all.

You are mixing software development and packaging. If you really want to
have something clean, you should avoid having changes into the source of
the upstream author (at least changes that should last).

Lets take an example:
* you commit source of project C, version V1 into your VCS
* you do everything required packaging, including some change to project
 C to make it compile (changeset P1)
* upstream author publish project C, version V2 (changeset P2) between V1
 and V2
* the changeset between P1 and P2 cannot merge
...

So what help do you get from your VCS here? You will have anyway to
rework it.

Forcing a VCS is just a way to loose people who won't have access to
your VCS... I don't see a real advantage of doing it...

If people want to put sources of anyone under their own VCS, they can do
it. You can do even something very clever: put a metadata about upstream
VCS into the packaging metadata. This way you will be able to checkout
upstream author VCS directly and be able to send them patches with their
own VCS... Better than to have to do a patch or to convert darcs/hg/git
changeset to send it...

Example:

File METADATA.opkg:
Upstream-Email: moi@chezmoi.com
Upstream-VCS: svn+ssh://chezmoi.com/mygreat-project/tags/1.0.0

or 

Upstream-VCS: darcs://chezmoi.com/mygreat-project@version_1.0.0

or 

Upstream-VCS: git://chezmoi.com/mygreat-project@version_1.0.0

(Upstream-VCS will be 

Of course, the file METADATA.opkg can and all the other packaging info
can be stored in any VCS (svn for GODI today).

>>>    - A build system integrated with the package management system,
>>>
>> 
>> Yes, if you do not force every software developers to use it and still
>> provide a way to integrate their software into your package management
>> system.
>
> We are not forcing anyone to work using the selected VCS.  We are just 
> asking them to regularly publish their software to the VCS.  If they 
> directly work using the selected VCS, publishing commits will be easier 
> for them - but they can still work on a day-to-day basis using their own 
> VCS.
>

Do they have to merge their changes with packager changes? In this case,
i really do think that upstream author won't publish their changes a
lot.

Regards,
Sylvain Le Gall