Browse thread
[OSR] Ports-like package management system
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Vlad Skvortsov <vss@7...> |
| Subject: | Re: [Caml-list] Re: [OSR] Ports-like package management system |
Sylvain Le Gall 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).
>
I agree with this. The lower the entry barrier for the system, the
better. The simplier the system, the better.
I wouldn't use a system that forces me to install a new sexy VCS on N of
my machines and learn a new workflow just to use some packaged module.
My strong preference is that any package should be available for
download via HTTP/FTP. The metadata (central package registry) can be
versioned or not, I don't care, as long as I can publish my package with
a single command.
I really like the way it's done in Python, here is a link to my previous
email on this topic:
http://www.nabble.com/Re:-Re:-On-module-distribution-p14852553.html
--
Vlad Skvortsov, vss@73rus.com, http://vss.73rus.com