debian package

[Mildred Ki'Lya]

Le Thu 04/09/2008 à 18:03 picca à écrit:
> > And everyone is free to push their branch either in gna (they have
> > ssh access but no easy web interface as far as I can see) or
> > somewhere else. For example http://gitorious.org
> 
> Yes or http://repo.or.cz where it is very easy to create "fork" of an
> original.

Use whatever provider you prefer (gitorious has a nice interface,
unlike Gforge unfortunately)

> > > the risk with git is to have a very complicate history if you do
> > > not have someone in charge of this. and becarefull the history
> > > can be modify 'a posteriory'.
> > 
> > How is that possible ?
> > Isn't the history hashed using SHA1 cryptographic algorithm. If you
> > manage to change the history (for example using git rebase) it
> > should also change the identifiers of the changesets.
> 
> Yes but if you publish somethings on the repository, someone clone it
> and start working on it.
> During the same time you do some rebase on the original repository. So
> you change it history. (the DAG of the repository changed)

You SHOULDN'T even THINK of publishing something you think you'll
rebase, this is INSANE. Or if you do, you must add a CLEAR NOTICE that
things are ready to move and no one can use what you've done as a
starting point for their work.

If someone really wants to use a such instable branch as a starting
point, there are possibilities, like Mercurial queues, or Quilt (this
is essentially the same thing). That is, using raw patches (and some
utilities to manage them, because by and, it's not always that easy)

Now, I would like to ask a question. I don't think in such situations
you need to use git rebase, do you ? Why don't use a simple merge ?

> Then the cloning guy come and say ok pull my 'next' branch from my
> repository published on repo.or.cz or whatever.
> His DAG is different and because you made a rebase of the original
> repository you obtain something ugly on the original repository after
> a simple pull.
> 
> The important think is to not modify the DAG and prefer pushing commit
> instead of rebasing in the original repository.
> 
> In your private repository you do what you want. :)

Exactly !

> > I have no idea how debian packages works, for me it is far too
> > complicated (creating a package should be something
> > straightforward). But I don't see the problem of keeping the debian
> > directory with the compiler. If we had no debian developer in the
> > team it would be another story, but that's not the case.
> 
> This is not about having or not a DD in the team.
> Debian builds its packages from the origianl tar.gz and a .diff file
> with the debian directory and all modifications of the original tar.gz
> made during the packaging.
> if the tar.gz already contain a debian directory the diff between this
> "original" debian directory and the one use for the packaging create a
> very ugly patch (.diff) file.
> 
> sometimes other peoples can modifiy your debian package and you need
> to reimporte it in the git repository. In fact the "debian official"
> package of lisaac can evolve indepedantly of lisaac.
> That is why I propose to put the debian directory in it's own branch.
> 

Well, in our case, I suppose the diff file is empty. So I don't see
exactly the issue... Doesn't matter


Mildred
-- 
Mildred Ki'Lya
╭───────── ｍｉｌｄｒｅｄ５９３＠ｏｎｌｉｎｅ．ｆｒ ──────────
│ Jabber, GoogleTalk: <mildred at jabber.fr>
│ Site: <http://ki.lya.online.fr>              GPG ID: 9A7D 2E2B
│ Fingerprint: 197C A7E6 645B 4299 6D37 684B 6F9D A8D6 9A7D 2E2B