Re: dpkg-source's future and relation with VCS

[Anthony Towns]

On Sun, Feb 24, 2008 at 11:48:44AM +0200, Guillem Jover wrote:
> So I don't quite like Joey's idea in its
> current form, for the reasons other people have stated on the thread:

*sigh* So dpkg isn't going to support it then?

Cheers,
aj



signature.asc
Description: Digital signature

Re: dpkg-source's future and relation with VCS

[Guillem Jover]

Hi,

On Mon, 2008-02-11 at 14:46:33 +0100, Raphael Hertzog wrote:
> On Mon, 11 Feb 2008, Frank Lichtenheld wrote:
> > For me this sentence is the essence of your mail: That you dislike
> > Joey's idea since it includes the VCS in the source package itself and
> > would prefer that we worked on creating a solution on top of wig&pen
> > instead.
> > 
> > Do I understand that correctly?
> 
> No. I don't dislike it at all, I do like distributed VCS and the workflow
> and I believe that when upstream is using a DVCS, the $vcs.tar.gz is a
> really nice approach.

I've been also thinking about all this (but didn't comment on the
initial discussion as I hadn't make up my mind), I do like DVCS as
well, and agree that when upstream is using a DVCS ideally the Debian
maintainer would use that to keep track of the changes, but not on the
source packages produced! So I don't quite like Joey's idea in its
current form, for the reasons other people have stated on the thread:

 * have to commit generated files
 * have to reupload all previous history every time
 * have to use shallow clones (git) otherwise it bloats
 * we switch from a myriad patch systems to a myriad DVCS
   - implies needing to install the DVCS to unpack the sources
   - implies needing knowledge about the DVCS to work with the source
 * not 100% guaranteed future compatibility with repo format
 * it forces specific workflows on the DVCS

Also the fact that a source package is a release format, a snapshot.
I don't see usually upstreams release .git tarballs, it does not make
sense. One can always use the upstream VCS anyway (or the one
containing the Debian packaging).

If, for example, we'd want to fix the problem of having to reupload
the previous history on each upload, by supporting incremental deltas,
this is mostly reinventing 'git push' in the git case. And then there's
the problem (minor) that one has to increase the upstream version and
reuplod the whole thing in case one wants to switch DVCS.

Patches are the common denominators, any VCS will be able to import and
export from them. That does not mean people has to work directly with
the source package, I think it makes the most sense to consider it
mostly an export and import format, but still basic enough so that more
complex tools can be built on top of it to handle or convert from/to it.

So I think this is the wrong approach, it seems to be reinventing the
DVCS (cloning, pushing, etc), poorly, and probably something like the
NoMoreSourcePackages[0] makes more sense, and shields all those VCS
behind ftp-master/buildds, and we get one standardized source format as
well as output, and the benefits of maintainers directly using DVCS or
even Non-DVCS.

About Wig & Pen (and Anthony's comments about lack of implementation),
I've just written a really simple and stupid script (proof of concept)
that converts an existing package (using quilt) to it. Can be tried
with something like, and it's attached to this mail:

  apt-get source fbset ppmd
  dsc2wnp fbset*.dsc
  dsc2wnp ppmd*.dsc
  dpkg-source -x *.dsc

regards,
guillem

[0] http://lists.debian.org/debian-devel/2006/07/msg00544.html
#!/bin/bash
#
# Proof of concept Wig & Pen package converter
#
# Required: gpg, procmail, perl, patchutils

set -e

fdsc=$1

echo "Switching $fdsc to Wig&Pen format..."

cp -f $fdsc $fdsc.orig

echo " getting rid of gpg signature..."

if gpg -d $fdsc > $fdsc.asc 2>/dev/null; then
  mv $fdsc.asc $fdsc
fi

echo " extracting information..."

dscfiles=`formail -z -xFiles <$fdsc | cut -d' ' -f4`
pkgdir=`echo "$dscfiles" | sed -n -e 's:_:-:;s:\.orig\.tar\.gz::p'`
fdiff=`echo "$dscfiles" | grep 'diff\.gz$'`
fdebian=`echo $fdiff | sed -e 's:diff:debian.tar:'`

paths="`zcat $fdiff | lsdiff --strip 1 | grep -v '^debian' || true`"
if [ -n "$paths" ]; then
  echo " diff modifies files outside debian/ dir, bailing out."
  exit 1
fi

echo " extracting sources..."

dpkg-source -x $fdsc

echo " remove quilt series file..."

rm -f $pkgdir/debian/patches/series

echo " rename patches to run-parts expected names..."

cd $pkgdir
rename 's:\.patch$::' debian/patches/*
rename 'tr:_\.:-:' debian/patches/*
cd ..

echo " converting $fdiff to $fdebian..."

tar czf $fdebian -C $pkgdir/debian/ .

echo " fixing $fdsc to refer to $fdebian..."

fdebian_size=`stat -c %s $fdebian`
fdebian_md5=`md5sum $fdebian | sed -e "s:  : $fdebian_size :"`

sed -i -e "s:^.* $fdiff$: $fdebian_md5:" $fdsc

echo " fixing $fdsc Format..."

sed -i -e 's/^Format: 1\.0/Format: 2.0/' $fdsc

echo " cleaning up after conversion..."

rm -f "$fdiff"
rm -rf "$pkgdir"

echo "done."

Re: dpkg-source's future and relation with VCS

[Russ Allbery]

Raphael Hertzog <[EMAIL PROTECTED]> writes:
> On Tue, 12 Feb 2008, Russ Allbery wrote:

>> Basically, the way to do this is to do the dbs thing, I think.  The
>> structure of the .tar.gz file would be:

>>  - All content in the .tar.gz file is in a debian subdirectory as packed.
>>  - debian/patches contains a quilt series file and set of patches.
>>  - debian/upstream contains one or more .tar.gz or .tar.bz2 files plus a
>>series file that specifies the order of unpack.
>
> This doesn't work well. Upstream tarballs inside a single .tar.gz
> requires reupload of all the upstream sources for every revision.
>
> (That's also one of the weak point of the VCS based format as implemented
> currently)

It's inherent to the VCS-based format so far as I can see.  Anyway, that's
one of the reasons why you'd want to convert to wig&pen instead for a
quilt-based package, I think.  It's a more efficient representation in
some respects.

I'm not sure how much of a problem this really is.

> The plugin architecture shouldn't assume a single tarball, it should
> receive as input the list of files contained in the .dsc and it should
> be able to use every file. This should be easy to do once the code in
> dpkg-source is factored out.

Yes, that would be nice.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-source's future and relation with VCS

[Raphael Hertzog]

On Tue, 12 Feb 2008, Russ Allbery wrote:
> Basically, the way to do this is to do the dbs thing, I think.  The
> structure of the .tar.gz file would be:
> 
>  - All content in the .tar.gz file is in a debian subdirectory as packed.
>  - debian/patches contains a quilt series file and set of patches.
>  - debian/upstream contains one or more .tar.gz or .tar.bz2 files plus a
>series file that specifies the order of unpack.

This doesn't work well. Upstream tarballs inside a single .tar.gz
requires reupload of all the upstream sources for every revision.

(That's also one of the weak point of the VCS based format as implemented
currently)

The plugin architecture shouldn't assume a single tarball, it should
receive as input the list of files contained in the .dsc and it should be
able to use every file. This should be easy to do once the code in
dpkg-source is factored out.

> > So way back in the day, I did try writing a conversion tool from darcs
> > to wig&pen and back -- the problems I had were that it was kludgy to
> > manage because of the way the patches weren't separated from everything
> > else (eg, there's nothing stopping a Wig&Pen patch from patching an
> > earlier/later Wig&Pen patch) and it was really slow to actually replay
> > through the darcs history to generate the patches.
> 
> This is definitely the hard part.  Going from a repository to wig&pen
> without any hints or additional information about how the repository is
> working is going to be either really hard or fairly unsatisfying.  It gets
> much easier if you can give the conversion hints (this is my debian
> branch, these are all of my feature branches, each feature branch is a
> separate patch, here's the order in which the feature branches are merged,
> that sort of thing).  Some of those hints may be extractable from the VCS,
> depending on the VCS.

This is why I believe a debian/sources.rules file makes sense. For simple
cases, one would just have to include standard rules (say
/usr/share/dpkg-dev/vcs/git.make), some special cases could be handled by
variables and very complex cases could have some custom logic not provided
by dpkg-dev.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-source's future and relation with VCS

[Russ Allbery]

Anthony Towns <[EMAIL PROTECTED]> writes:

>   - Raphael's looking at enhancing the wig&pen format (eg, adding
> a file explicitly listing patches to apply), and making
> dpkg-source able to generate a wig&pen format package; Russ may
> be looking at automating the process of generating wig&pen format
> packages for packages maintained using quilt

So, I slept on this, and it really doesn't look hard.  It doesn't look
like wig&pen, but I'm pretty sure you can easily programmatically convert
from this format to wig&pen and vice versa.  (Joey's plugin infrastructure
is *wonderfully* easy to understand.)

Basically, the way to do this is to do the dbs thing, I think.  The
structure of the .tar.gz file would be:

 - All content in the .tar.gz file is in a debian subdirectory as packed.
 - debian/patches contains a quilt series file and set of patches.
 - debian/upstream contains one or more .tar.gz or .tar.bz2 files plus a
   series file that specifies the order of unpack.

On unpack, you:

 * Extract the tar.gz, which gives you an almost empty directory with only
   a debian subdirectory.

 * For each upstream tar file in debian/upstream/series, extract that tar
   file into a working tmp directory.  (This will require messing with how
   the tar files extract since they may use different base directories,
   but that's a solved problem from other tools.)  Files found in later
   tar files overwrite files found in earlier tar files.

 * Lift the contents of the tmeporary directory up one level so that the
   result looks like a regular Debian package looks today.  Making
   everyone work in a subdirectory requires unnecessarily annoying
   fiddling in debian/rules.

 * Run quilt push -a or the moral equivalent with QUILT_PATCHES pointing
   to debian/patches.

To create such a package from a quilt working tree, you:

 * Check to see if the complete patch set is still applied (using quilt
   applied and checking against debian/patches/series).  If a different
   set of patches are applied than are listed in series, you assume that
   the person working in the source tree knows how to use quilt and you
   run quilt pop -a to get a clean tree and error out if quilt pop -a
   fails.

   If all the patches are applied, the person may not have paid any
   attention to quilt, and you need to recover any additional changes.  To
   do that:

- Move all non-debian files down one level into a temporary working
  directory.

- Create a second temporary working directory by unpacking the
  upstream source tarballs and then doing a quilt push -a in that
  second directory roughly as described above.

- diff -r between the directories.  If the diff is empty, there are no
  changes not captured as patches.  If the diff is non-empty, save
  that diff in debian/patches with a unique name and add it to the end
  of the series file.

 * Remove everything other than the debian directory.

 * Make a tar file of the result.

So, what you get with this package format is the debian directory put
directly in the tarball (so you can add binary files there, etc.), a
debian/upstream directory that can contain as many overlapping upstream
tar files as needed, and a debian/patches directory with a series file
recording all the patches.  Transformation into the wig&pen format should
be trivial.  The patches can be generated by appending increasing numbers
to the patch files based on their order in the series file.

> So way back in the day, I did try writing a conversion tool from darcs
> to wig&pen and back -- the problems I had were that it was kludgy to
> manage because of the way the patches weren't separated from everything
> else (eg, there's nothing stopping a Wig&Pen patch from patching an
> earlier/later Wig&Pen patch) and it was really slow to actually replay
> through the darcs history to generate the patches.

This is definitely the hard part.  Going from a repository to wig&pen
without any hints or additional information about how the repository is
working is going to be either really hard or fairly unsatisfying.  It gets
much easier if you can give the conversion hints (this is my debian
branch, these are all of my feature branches, each feature branch is a
separate patch, here's the order in which the feature branches are merged,
that sort of thing).  Some of those hints may be extractable from the VCS,
depending on the VCS.

>> If tailor works now as a many-to-many conversion tool, that would
>> address my concern even better.

> Uh, you don't know about tailor? http://progetti.arstecnica.it/tailor

I know about it.  I just haven't used it in anger and I don't know how
well it tackles these problems.  A quick review of its documentation gave
me the impression that it's fairly fiddly, but that's only a first
impression and I don't want to make any judgement until I'd had time to
actually try it (or someone else tells me that it's really easy).

-- 
Russ A

Re: dpkg-source's future and relation with VCS

[Raphael Hertzog]

On Wed, 13 Feb 2008, Anthony Towns wrote:
> On Mon, Feb 11, 2008 at 02:46:33PM +0100, Raphael Hertzog wrote:
> > However I'm also convinced that:
> > - a source package should be unpackable without a VCS. This means that
> >   somehow it should contain a checkout that can be extracted with basic
> >   tools. [1]
> 
> I don't think it's feasible to require that. It's a great goal, but
> we're not there, and may not be there by lenny; and having a better
> source format for lenny+1 is more important than that goal.

It is easily feasible. However if we do it, we'll have bigger source
packages and you can't allow upload of those to ftp-masters. I still
believe it to be a worthy goal... at least to match those requirement
(taken in one of your messages):
- doesn't requires lots of dependencies on other code
- doesn't become obsolete and block you from unpacking old
  source packages

We can extract without VCS and have a look at stuff. Even if the DVCS
doesn't handle a 10-year old repository, we still have the content even if
we don't have access to the history.

It might be worth discussing on the upstream git mailing list to see how
we can save maximum of space while keeping a checkout.

> > - it will take several years until we can standardize on VCS-based source
> 
> I don't think we have a VCS-equilvaent source package format that's worth
> considering standardising on: .tgz and .orig/.diff aren't powerful enough,
> git and bzr are too system specific, and wig&pen is too unimplemented.

I already stated my intent to work on a wig&pen based format. 

(We only have two months from now (until beginning of April) to add new
features to dpkg/dpkg-dev)

I don't plan to block anything concerning VCS-based formats, however I do
believe that the mixed approach I outlined fit better the Debian community
as a whole given that it can also be usefully combined with VCS. 

It simply gives two workflows:
- the maintainer workflow "debcheckout, hack, debcommit, debuild"
- the NMUer workflow "apt-get source, hack, debuild"

> So while I'm not exactly disagreeing with either premise, I don't think
> it makes sense to consider them atm. If they do eventually work out, to
> the point that dpkg will auto convert VCS-managed repos to tar+patches
> and back again in useful and convenient ways, then we can start REJECTing
> .git/.bzr/.hg/whatever uploads that we will have been accepting in the
> meantime, and expect maintainers to do that.

Fine. I just want constructive comments so that my work brings us closer
to that goal. :-)

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-source's future and relation with VCS

[Anthony Towns]

On Tue, Feb 12, 2008 at 12:51:12AM -0800, Russ Allbery wrote:
> Anthony Towns <[EMAIL PROTECTED]> writes:
> > My point is precisely that it's *NOT* useful now.
> No software is useful until it is implemented.  wig&pen is far from unique
> in that regard.

Right, but the git/bzr stuff _is_ implemented...

Skipping to the end:

> > I'd love to see both those things fixed so we can upload packages in any
> > format after lenny's released; but I'd hate to see git/bzr format get
> > blocked on Wig&Pen, and then miss out on lenny because Wig&Pen just
> > isn't up to snuff and have us end up with neither for another cycle.
> On this we agree -- I see no reason why adopting the VCS format should be
> in any way dependent on wig&pen.

Good -- that's the only thing I'm saying here.

AFAICS where we're at is:

- we've got a new plugin architecture for supporting source
  package formats, which will at least cover v3 source formats for
  git/bzr tarballs. It needs some minor finalisation (behaviour
  when there are uncommitted changes, Source-Depends), but
  that's it.

- the dpkg-source code might be cleaned up, to have a Dpkg::Source
  API (Raphael) and to use the plugin architecture for the v1
  and v2 source formats too (Frank).

- Raphael's looking at enhancing the wig&pen format (eg, adding
  a file explicitly listing patches to apply), and making
  dpkg-source able to generate a wig&pen format package; Russ may
  be looking at automating the process of generating wig&pen format
  packages for packages maintained using quilt

- none of the new formats are accepted by the archive; to become
  accepted, any particular format needs:

- a demo of the format working effectively, so we can see
  what it takes to maintain a package with it, and what the
  actual output is, and to use as a test case

- the format to be supported in dpkg mainline

- the format to be unpackable by users running stable
  (ideally with apt-get and dpkg-source -x; but possibly
  by hand, or with a backported package)

  as well as an appropriate patch to dak.

> This, however:
> > I haven't used quilt, but I don't believe there's anything that would
> > make it difficult to port Joey's git plugin to being a quilt plugin.
> sounds like convergence towards exactly what Raphael was talking about,
> no?  

That's not what I got from:

] - dpkg-dev (or dpkg-dev-vcs) provides VCS-specific scripts in
]   /usr/share/dpkg-dev/ that can be used to generate a wig&pen source
]   package from a VCS repository

and more particularly:

] However I'm also convinced that:
] - a source package should be unpackable without a VCS. This means that
]   somehow it should contain a checkout that can be extracted with basic
]   tools. [1]
] - it will take several years until we can standardize on VCS-based source
]   package whereas the switch to wig&pen can be quick. In the mean time, a
]   nice intermediary solution is to generate the wig&pen source package
]   from the VCS.

I don't think standardising on a VCS is an option, be it git or quilt or
anything else; and I do think standardising on a format, at least with
the technology we have now or are likely to have soon will require that.

We've got a bunch of requirements:

- dpkg-source -x can unpack to the bare code
- can manage a large number of Debian specific patches
- can easily merge with upstream changes
- can easily merge with downstream changes (Ubuntu, local admin, etc)
- doesn't require any learning on behalf of maintainers
- doesn't require any learning on behalf of NMUers
- doesn't require any learning on behalf of admins/users
- doesn't requires lots of dependencies on other code
- doesn't become obsolete and block you from unpacking old source
  packages

Standardising on a single source format isn't that important, and afaics
avoiding making people install git-core, bzr, darcs, quilt, etc isn't
either -- getting all the above right is though.

> So maybe this is a good way forward.  A quilt plugin to that
> framework that also has hooks to unpack multiple tarballs ends up looking
> remarkably like wig&pen, and then the argument about whether we can or
> should convert to and from that format can be decoupled from the issues
> around the availability of the format itself.
> 
> In fact, that would largely reduce all issues of conversion to a simple
> technical implementation detail that people could work on or not as it
> felt useful, which seems like exactly where we'd want to be.

So way back in the day, I did try writing a conversion tool from darcs to
wig&pen and back -- the problems I had were that it was kludgy to manage
because of the way the patches weren't separated from ever

Re: dpkg-source's future and relation with VCS

[Anthony Towns]

On Mon, Feb 11, 2008 at 02:46:33PM +0100, Raphael Hertzog wrote:
> However I'm also convinced that:
> - a source package should be unpackable without a VCS. This means that
>   somehow it should contain a checkout that can be extracted with basic
>   tools. [1]

I don't think it's feasible to require that. It's a great goal, but
we're not there, and may not be there by lenny; and having a better
source format for lenny+1 is more important than that goal.

> - it will take several years until we can standardize on VCS-based source

I don't think we have a VCS-equilvaent source package format that's worth
considering standardising on: .tgz and .orig/.diff aren't powerful enough,
git and bzr are too system specific, and wig&pen is too unimplemented.

So while I'm not exactly disagreeing with either premise, I don't think
it makes sense to consider them atm. If they do eventually work out, to
the point that dpkg will auto convert VCS-managed repos to tar+patches
and back again in useful and convenient ways, then we can start REJECTing
.git/.bzr/.hg/whatever uploads that we will have been accepting in the
meantime, and expect maintainers to do that.

Cheers,
aj



signature.asc
Description: Digital signature

Re: dpkg-source's future and relation with VCS

[Russ Allbery]

Russ Allbery <[EMAIL PROTECTED]> writes:

> It's certainly trivial to convert a package that uses quilt to the Git
> format.  You just import the upstream tarball on an upstream branch, clone
> it to master, create a feature branch for every patch, merge them all into
> master in the order specified by the series file, create a debian branch,
> add the debian directory on that branch, and merge that branch into
> master).  In fact, it's basically this script:
>
> git init
> git checkout -b upstream
> dpkg-source -x ../ .
> rm -rf debian
> git add .
> git commit
> git checkout master
> git merge upstream
> git checkout -b debian
> dpkg-source -x ../ .
> mv debian/patches ../patches
> git add debian
> git commit
> git checkout master
> for patch in `cat ../patches/series` ; do
> git checkout -b "feature/$patch"
> patch -p1 < ../patches/"$patch"
> git commit
> git checkout master
> git merge "feature/$patch"
> done
> git checkout master
> git merge feature/`tail -1 ../patches/series`
> git merge debian

Uh, sorry, ignore the last two lines above git merge debian.

As recompense, unless I'm missing something, the trivial quilt
implementation of the v3 source format would look basically like this:

sub prep_tar {
system('quilt', 'pop', '-a');
}

sub post_unpack_tar {
chdir($srcdir)
or main::syserr(sprintf(_g("unable to chdir to `%s'"), $srcdir));
system('quilt', 'push', '-a');
}

As with the initial cut at the bzr plugin, though, there are details to be
worked out, particularly around what to do with uncommitted changes.
You'd probably also want to plug pristine-tar into this picture and save
off the delta (and similarly would want to do that with the Git format) so
that you can regenerate the pristine tarball for checksum comparison with
upstream and diffing against the tree to ensure that you haven't missed
any changes.

There are details to work out, but it looks pretty straightforward to me.
The hardest part is to make uncommitted changes sane for non-quilt users.
I'd be tempted to just recursively quilt add every file in the tree to a
new empty patch after unpacking the source tree, since then you can easily
quilt refresh that top patch and save it off before running quilt pop.
That does double the size of the checked-out tree, though

I'm going to bed now.  :)

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-source's future and relation with VCS

[Russ Allbery]

Anthony Towns <[EMAIL PROTECTED]> writes:

> My point is precisely that it's *NOT* useful now.

> The other VCS systems are, because they *have* the VCS backend you need
> to manage and manipulate history/changesets/patches/etc. Wig&Pen isn't,
> because it doesn't have those tools.

No software is useful until it is implemented.  wig&pen is far from unique
in that regard.

The fundamental point of disagreement that we seem to have is that you
think that implementing conversion to and from wig&pen is hard, whereas I
think I disagree (it looks pretty trivial to me for the large number of
Debian packages that currently use dbs, quilt, dpatch, or simple-patchsys,
and not horribly difficult for straight Git and bzr repositories that use
branches).  Since I don't we're going to resolve that argument until
someone tries, there doesn't seem to be much point in arguing about it, I
guess.

This, however:

> I haven't used quilt, but I don't believe there's anything that would
> make it difficult to port Joey's git plugin to being a quilt plugin.

sounds like convergence towards exactly what Raphael was talking about,
no?  So maybe this is a good way forward.  A quilt plugin to that
framework that also has hooks to unpack multiple tarballs ends up looking
remarkably like wig&pen, and then the argument about whether we can or
should convert to and from that format can be decoupled from the issues
around the availability of the format itself.

In fact, that would largely reduce all issues of conversion to a simple
technical implementation detail that people could work on or not as it
felt useful, which seems like exactly where we'd want to be.

> Uh, you're discussing something other than Wig&Pen then...

Er, yes, there was a whole debian-devel discussion about how wig&pen
should change to be a useful representation of existing practice, and that
was what Raphael's original message was based on.  If you weren't aware of
that, that might go a long way towards why we're talking at
cross-purposes.

Anyway, http://wiki.debian.org/GitSrc sums up the concern I have about a
VCS-driven package format:

| Q: But doesn't this mean that people have to learn git to contribute to
| or NMU my package?
| 
| A: Yes, contributors or NMUers will need to know some basic git commands
| like "git commit -a", since any change they make needs to be checked in
| before the package is built.
| 
| Q: Might this not be the start of a slippery slope? I don't mind
| learning git, but what if we get a dozen other revision control systems
| used in source packages?
| 
| A: It will be up to the dpkg developers to keep things sane. (Obligatory
| comment about sanity of dpkg developers elided. ;-) On the other hand,
| having a real revision control system available in the source package
| format leaves need for dbs and all its ilk. You have to learn them too,
| before contributing to a package that uses them. So in the end adding
| git to the source format might make things simpler and more
| standardised.

The goal is to fix the underlying problem that right now you have to know
the tools of the package maintainer in order to maintain the package.
Both a multitude of VCS-driven package formats and wig&pen are a huge
improvement over the current state.  Even if we have a VCS package format
for every VCS known to man, it's already a huge improvement over the
current state because you can at least hack on the package in basic ways
without learning the VCS (provided that dpkg-source can do the basic
commit for you), or learning only the most minimal commands.

I see some potential in wig&pen for something even better than that in the
current environment of no VCS agreement, namely a common interchange
format that lets people use the VCS of their choice and generate packages
that anyone else can similarly use the VCS of their choice on to do
moderately complex (but not the most difficult) operations on.

If tailor works now as a many-to-many conversion tool, that would address
my concern even better.  The point of wig&pen would be to be a conversion
hub that everything could speak; if that's not easier to implement than
direct conversion, then obviously there's no point in having it.

It's certainly trivial to convert a package that uses quilt to the Git
format.  You just import the upstream tarball on an upstream branch, clone
it to master, create a feature branch for every patch, merge them all into
master in the order specified by the series file, create a debian branch,
add the debian directory on that branch, and merge that branch into
master).  In fact, it's basically this script:

git init
git checkout -b upstream
dpkg-source -x ../ .
rm -rf debian
git add .
git commit
git checkout master
git merge upstream
git checkout -b debian
dpkg-source -x ../ .
mv debian/patches ../patches
git add debian
git commit
git checkout master
for patch in `cat ../patches/series` ; do
git checkout -b "

Re: dpkg-source's future and relation with VCS

[Anthony Towns]

On Mon, Feb 11, 2008 at 10:37:50PM -0800, Russ Allbery wrote:
> > It does have history:
> > upstream:   (unpack all the tarballs)
> > upstream+1: (apply the first patch from .debian.tgz /patches)
> > upstream+2: (apply the second patch from .debian.tgz /patches)
> > ...
> > debian: (apply the last patch from .debian.tgz /patches)
> That isn't history.  There isn't a chronological or derivational order,

Uh, yes, there is an ordering -- the spec explicitly requires run-parts
ordering.

It might not be the ordering as originally developed; but a git tree
isn't necessarily that either, thanks to rebasing, and nor is a darcs
tree, thanks to merging and patch reordering.

> I can switch to mathematics (somewhat) if that helps.  A changeset
> collection forms a bounded lattice.  

Uh, right...

> No one is questioning that you can't do everything you might potentially
> want to do with wig&pen.

You can't create and maintain a package with wig&pen, even ignoring the
other stuff.

> The point is that wig&pen is a useful
> interchange format that's useful now when we don't agree on what VCS to
> use,

My point is precisely that it's *NOT* useful now.

The other VCS systems are, because they *have* the VCS backend you need to
manage and manipulate history/changesets/patches/etc. Wig&Pen isn't, because
it doesn't have those tools.

> You can't work usefully work on a Git source package using bzr or quilt

...without converting from a git repository to a bzr or quilt repository.

Likewise, you can't usefully on a Git source package with Wig&Pen without
converting it to a Wig&Pen repository, with the extra disadvantage that
tools to do that don't actually exist.

> without losing the conceptual clarity of the changesets.  You can work on
> a wig&pen package in Git, bzr, or quilt while retaining that.  

I'm sorry, but you're mistaken. You _can't_ do that. If you wrote a
whole bunch of tools to do it, you could, yes -- but you could do the
same with git and bzr given the tools too; and as it happens tailor
already exists and has that functionality.

> That's the
> difference, and the reason why it's not obvious to me that jumping
> directly to a VCS is a good idea.

Try creating and maintaining a package using git/bzr, and the git/bzr patches
for dpkg.

Try creating and maintaining the same package using wig&pen format.

One's possible and easy, the other's not.

> The VCS-based source format becomes very compelling once we all use the
> same VCS, 

No, any VCS-based source format is compelling once you use a single VCS
for a given package; and having it integrated into dpkg is immediately
compelling for anyone who wants to be able to hack on a package as soon
as they've downloaded and unpacked it.

Trying to force a single VCS on every package is a non-starter, whether
it's git, bzr or wig&pen. Different VCS's have different features:
git's fast, bzr's good at merging, wig&pen's good at looking at by hand;
git's hard to look at by hand, wig&pen has no tool support.

Converting different VCSs to a single format for distribution is a good
idea in theory -- hey, I was all for Wig&Pen back in 2005 -- but it turns
out to be lossy, slow and difficult; and doesn't actually buy anything
we can't already handle anyway.

> Basically, a Git package is more useful than wig&pen if you're using Git,
> and less useful than wig&pen if you're using anything else (except no
> tools at all, in which case both are equally useful).

It's not possible to automatically merge patches with wig&pen.
It's not possible to automatically create a source package with wig&pen.
No upstream uses wig&pen.
No one else is writing tools for manipulating wig&pen.

There are only two advantages to wig&pen: it doesn't suffer from
NIH-syndrome, and it's easy to unpack by hand.

> > Are you able to use the .git source package format right now? Yes, you
> > grab Joey's sources, create a package with git, and you're done. You
> > can't upload it to the archive, because it's not supported by dpkg in
> > stable, but that's it.
> > By contrast, you can't even get that far with Wig&Pen. And the reason
> > is that you've got a new VCS format, without the tools to go with it.
> This doesn't mean anything other than no one was interested enough by the
> idea to implement it.  If Raphael is now, I for one am going to cheer the
> effort on, since wig&pen is more useful to me immediately than the Git
> package format is.

You have an odd definition of "useful to me immediately" when you're
happy to apply it to something that doesn't work for anyone, but not to
something that does work...

> That doesn't mean that's all I want.  I really want to see both.  But I
> will start using wig&pen *now*, 

No, you won't, because you *can't*. You can't even use dpkg to _create_
the packages to put on your own website.

> whereas Git is going to take a while.

Whereas you could do that, right now, at least for packages you're
not uploading. You could do the sa

Re: dpkg-source's future and relation with VCS

[Russ Allbery]

Joey Hess <[EMAIL PROTECTED]> writes:
> Russ Allbery wrote:

>> (it's not yet clear to me that Git can usefully represent changesets
>> via feature branches, but that's another argument that is already
>> ongoing elsewhere).

> People are arguing about that because bikeshedding and random discussion
> of lattices, is, apparently, fun.

Actually, no, it isn't.  The emotion that I'm feeling is frustration
rather than fun.  Which may well mean that I just shouldn't do it and just
let the whole thing go if I don't agree rather than trying to explain why
don't agree.

However, if I did that, I'd miss prompting some really interesting bits of
information...

> apt-cache show stgit

...like this.

This is fascinating because it changes the underlying assumption
entirely.  This *doesn't* maintain patches as feature branches, which is
the solution that I'd heard before.  It maintains patches as git commits,
which is a much more natural solution and makes considerably more sense to
me (since fundamentally that's what a patch is, whereas maintaining
patches as feature branches undoes the node to arrow transformation that's
fundamental to why I find git useful).

Thank you!  I now need to go play with this.  This may give me exactly
what I want.  I'm sorry that I didn't look at this thoroughly before.

(The main open question that I have at the moment is whether StGIT can
maintain history of the commits, which is something that quilt + a VCS can
do and which is occasionally useful.  But I need to dig in further to
understand what it can or can't do.)

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-source's future and relation with VCS

[Joey Hess]

Russ Allbery wrote:
> (it's not yet clear to me that Git can usefully represent changesets
> via feature branches, but that's another argument that is already
> ongoing elsewhere).

People are arguing about that because bikeshedding and random discussion
of lattices, is, apparently, fun. 

apt-cache show stgit

-- 
see shy jo


signature.asc
Description: Digital signature

Re: dpkg-source's future and relation with VCS

[Russ Allbery]

Anthony Towns <[EMAIL PROTECTED]> writes:

> A VCS is a system for controlling (managing, distributing) versions of a
> repository.
>
> A Debian source package is a repository.

It's a changeset or a set of changesets.  This is not a repository any
more than a collection of objects is a balanced red/black tree.  Only a
tiny subset of the changesets and metadata you'd need to make a repository
would be represented in wig&pen because wig&pen would only represent a cut
of the current state.

> It does have history:
>
>   upstream:   (unpack all the tarballs)
>   upstream+1: (apply the first patch from .debian.tgz /patches)
>   upstream+2: (apply the second patch from .debian.tgz /patches)
>   ...
>   debian: (apply the last patch from .debian.tgz /patches)

That isn't history.  There isn't a chronological or derivational order,
and the patches are not based on each other in that fashion.  That's
dependency management between changesets, which is something else (and
most of the dependencies in a series file are actually fake -- a
limitation of the representation format).  This is a component that you
need to construct a VCS, but it isn't itself a VCS.  In this case, it's
using that component to do something different than what a VCS is.

Yes, you can implement a VCS with quilt, but if you do, you're abusing
quilt and you'll be very unhappy because it doesn't have the tools that
you need to really do a VCS.  But it's a great way of representing
changesets.

I think you're trying to simplify in order to see underlying patterns and
build a foundational framework for reasoning about this area, but in my
opinion you're being reductionist to the point of losing fundamental
distinctions.

>> It simply doesn't bundle together all of the changes into one blob of
>> "Debian work" and instead presents a bunch of separately appliable and
>> analyzable changes.

> Which is exactly what "history" is.

No, it isn't.  A history would include the history of each change, for
example, as well as the changes that you had made previously and no longer
do.  A history is something much larger than this, includes a
chronological component, and permits reconstruction of previous versions.

"Upstream source with one changeset applied" is not a previous version in
any meaningful definition of previous: it's not conceptually previous, and
since frequently that was the *last* changeset developed, it's not
chronologically previous either.

A patch management system stores only the current state, but with metadata
about how that state is conceptually assembled.  It's a cut across a
history.  It bears the same resemblence to a history as a core dump does
to a trace of a process over its whole lifetime.

I can switch to mathematics (somewhat) if that helps.  A changeset
collection forms a bounded lattice.  It is inherently constrained to a
bounded lattice: it describes how to form the top from the bottom.  Each
new upstream release of a Debian package represented by a changeset
collection rebuilds the bounded lattice from a new bottom and does not
retain any information (history) about how the previous bounded lattice
was constructed.

A VCS repository constrained to be a bounded lattice is crippled to the
point of not being worth the name.  A VCS repository is a generalized
partial order.

> The reason why Wig&Pen has never worked is precisely because it's not a
> real VCS: it's just a repository format, it doesn't have the tools to
> manage a repository. Which means it's not possible to create and
> maintain a package in Wig&Pen format, which is why it's not actually
> usable, inside or outside of Debian.

> For example, you talk about "separately analyzable" changes -- but
> wig&pen doesn't give you that: its changes are ordered to allow multiple
> changes to affect a single file, and unlike tools like darcs, there
> isn't any automated way to deal with dealing with corner cases when
> rearranging changesets; let alone merging changesets.

Right, because it's not a VCS.  It doesn't need to provide any of those
things to be useful as an interchange format.  If you want to perform
those operations, you import the interchange format into the structure of
a VCS and then use the VCS to handle that, or you go to the original VCS
which has history (in particular, merge history) and therefore a much
richer set of metadata to work from.

No one is questioning that you can't do everything you might potentially
want to do with wig&pen.  The point is that wig&pen is a useful
interchange format that's useful now when we don't agree on what VCS to
use, because every VCS and many things (like quilt and dpatch) that are
not VCSes but only changeset manipulators can already usefully use wig&pen
as an interchange format.

You can't work usefully work on a Git source package using bzr or quilt
without losing the conceptual clarity of the changesets.  You can work on
a wig&pen package in Git, bzr, or quilt while retaining that.  That's

Re: dpkg-source's future and relation with VCS

[Joey Hess]

Anthony Towns wrote:
> Are you able to use the .git source package format right now? Yes, you grab
> Joey's sources, create a package with git, and you're done. You can't
> upload it to the archive, because it's not supported by dpkg in stable, but
> that's it. 

It's also not supported by the many hardcoded filename bits in dak,
FWIW.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: dpkg-source's future and relation with VCS

[Anthony Towns]

On Mon, Feb 11, 2008 at 08:26:23PM -0800, Russ Allbery wrote:
> Anthony Towns <[EMAIL PROTECTED]> writes:
> > I think it's a mistake to separate those -- our source package format is
> > a VCS system; if wig&pen happens to be a more suitable VCS, that's fine,
> > but it's not inherently superior or inferior to any other VCS, just
> > because it happens to be Debian-specific.
> I very strongly disagree with this use of terminology.

A VCS is a system for controlling (managing, distributing) versions of
a repository.

A Debian source package is a repository.

We want to make multiple versions of that repository available (in
particular, a history from the last upstream version to the current
Debian revision, so that it's possible to separate each change).

You can disagree however strongly you like, but viewing Debian source
packages as a VCS isn't a particular stretch, and, IMO, gives a much
better overall perspective for looking at what we're trying to achieve;
and for that matter, why Wig&Pen didn't achieve it.

> Our source package format is not a VCS system currently.  

Yes, it is; the problem is that it naturally only supports two versions
(upstream and Debian), and has further limitations on how they can
differ. (Or if you're looking at native packages, only one version)

> It is a way of
> representing two works that combine into a source package, but thinking of
> that as a VCS just results in a bunch of conclusions that muddy the whole
> issue.  There is no history, and history is the entire point of a VCS.

There _is_ history, both in the form of debian/changelog, which
descriptively goes back beyond the actual code changes that are
represented, and the single step back to upstream.

And history is _precisely_ what we're interested in extending, whether
by dbs/dpatch/whatever, wig&pen, git, bzr or otherwise.

> wig&pen isn't a better VCS; it's a better way of representing the current
> state of the tree.  It still doesn't have any history.  

It does have history:

upstream:   (unpack all the tarballs)
upstream+1: (apply the first patch from .debian.tgz /patches)
upstream+2: (apply the second patch from .debian.tgz /patches)
...
debian: (apply the last patch from .debian.tgz /patches)

> It simply doesn't
> bundle together all of the changes into one blob of "Debian work" and
> instead presents a bunch of separately appliable and analyzable changes.

Which is exactly what "history" is.

> When we call that a VCS, we get into endless arguments about how we should
> use a real VCS, 

The reason why Wig&Pen has never worked is precisely because it's not
a real VCS: it's just a repository format, it doesn't have the tools
to manage a repository. Which means it's not possible to create and
maintain a package in Wig&Pen format, which is why it's not actually
usable, inside or outside of Debian.

For example, you talk about "separately analyzable" changes -- but wig&pen
doesn't give you that: its changes are ordered to allow multiple changes
to affect a single file, and unlike tools like darcs, there isn't any
automated way to deal with dealing with corner cases when rearranging
changesets; let alone merging changesets.

You ask later:

> Am I able to upload a wig&pen source package right now?  My impression was
> that it was never tried.

Are you able to use the .git source package format right now? Yes, you grab
Joey's sources, create a package with git, and you're done. You can't
upload it to the archive, because it's not supported by dpkg in stable, but
that's it. 

By contrast, you can't even get that far with Wig&Pen. And the reason
is that you've got a new VCS format, without the tools to go with it.

> how people don't want to dumb down their VCS into a patch
> format, and so forth, which are all red herrings created by the mistaken
> terminology.  

Using a real VCS with a more powerful change representation than textual
diffs has benefits; discussing those benefits isn't "endless arguments"
about "red herrings".

> If our source format is like anything, it's like a
> changeset or collection of changesets in the old arch definition, with no
> ordering and no history.  

Our current format is a single changeset, yes. Wig&Pen does introduce
ordering ("via the same rules as run-parts") and does introduce history,
just as git, bzr, or any other VCS with multiple versions does.

> It is, in other words, an interchange format.
> If we present it in that fashion, we avoid a lot of futile discussions.

Interchange is an important part of a VCS, yes. Which is one reason
to use existing VCS formats (like tar+patch, like git, like bzr, etc),
instead of creating our own.

Treating the "dpkg source format" as something different to a VCS, even
though it happens to have almost the exact same requirements, leaves us
open to the trap of thinking whatever we invent, as Debian specialists,
is going to naturally be more suitable than existing solutions. It's not.

> > i

Re: dpkg-source's future and relation with VCS

[Russ Allbery]

Anthony Towns <[EMAIL PROTECTED]> writes:

> I think it's a mistake to separate those -- our source package format is
> a VCS system; if wig&pen happens to be a more suitable VCS, that's fine,
> but it's not inherently superior or inferior to any other VCS, just
> because it happens to be Debian-specific.

I very strongly disagree with this use of terminology.

Our source package format is not a VCS system currently.  It is a way of
representing two works that combine into a source package, but thinking of
that as a VCS just results in a bunch of conclusions that muddy the whole
issue.  There is no history, and history is the entire point of a VCS.

wig&pen isn't a better VCS; it's a better way of representing the current
state of the tree.  It still doesn't have any history.  It simply doesn't
bundle together all of the changes into one blob of "Debian work" and
instead presents a bunch of separately appliable and analyzable changes.

When we call that a VCS, we get into endless arguments about how we should
use a real VCS, how people don't want to dumb down their VCS into a patch
format, and so forth, which are all red herrings created by the mistaken
terminology.  If our source format is like anything, it's like a
changeset or collection of changesets in the old arch definition, with no
ordering and no history.  It is, in other words, an interchange format.
If we present it in that fashion, we avoid a lot of futile discussions.

> ie, "that can be used to covert from the VCS used in development to
> wig&pen VCS".

This is not what those scripts do.  If they did that, they'd retain
history, which is entirely not the point.  What those scripts do is
transform the head of the VCS into an interchange format that can either
be worked on as-is or imported into a different VCS.  It loses all the VCS
metadata (intentionally) but retains the separation of conceptually
different changes.

> So far, wig&pen has objectively failed as a source format; please let
> the git/bzr/etc format succeed or fail on its own merits, without tying
> it to a wig&pen resurrection attempt...

Am I able to upload a wig&pen source package right now?  My impression was
that it was never tried.

I agree with Raphael: wig&pen has more immediate appeal for widespread
adoption than a VCS-based system, even if a VCS-based system is better in
the long run.  This is easily seen by looking at the archive.  wig&pen is
essentially what everyone who is using quilt or dpatch is already doing.
It's a standardization of current practice, which is always easier.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-source's future and relation with VCS

[Anthony Towns]

On Mon, Feb 11, 2008 at 12:48:19PM +0100, Raphael Hertzog wrote:
> I believe the wig&pen format [1] solves most of those concerns. I believe
> that with some minor changes, it would satisfy the need of most packages
> (even those using complicated build system).

> But the complicated part comes when we try to think of interactions
> between VCS and source package format. 

I think it's a mistake to separate those -- our source package format
is a VCS system; if wig&pen happens to be a more suitable VCS, that's
fine, but it's not inherently superior or inferior to any other VCS,
just because it happens to be Debian-specific.

If you look at it that way, then instead of having a ".git" directory
with metainfo about the package, you have a "debian/patches" directory
(and some tarballs in ../ probably); instead of a dpkg-source plugin that
generates a .git.tar.gz you have a dpkg-source plugin that generates a
set of wig&pen tarballs.

> I'd like to keep the (default)
> source package format mostly VCS agnostic

If you think about it that way it's meaningless to say the source package
format is "VCS agnostic" -- it _is_ a VCS all on its own.

> - dpkg-dev (or dpkg-dev-vcs) provides VCS-specific scripts in
>   /usr/share/dpkg-dev/ that can be used to generate a wig&pen source
>   package from a VCS repository

ie, "that can be used to covert from the VCS used in development to
wig&pen VCS".

Note that VCS conversion is harder (and slower) than it looks.

> - the package's repository contains a debian/source.rules that provides a
>   target "build" to create the wig&pen source package,

You shouldn't need to write any code to create a source package -- that's
what dpkg is for. 

> - note that debian/sources.rules could support a "build-v3" target that

(Ugh...)

> - also note that we can have several variants of the build scripts even
>   for a single VCS (think one using feature branches and one that doesn't)

The git way of looking at that would be "same scripts, but different
branch"; the debian/patches way of looking at it would be "same scripts,
but different patches enabled". Other VCS'es would probably require a
different checkout/source package entirely (CVS, darcs). That shouldn't
need per-package code (in debian/rules or similar), just per-VCS code (eg,
"git branch").

> - in any case, I suggest using the Build-Options: field discussed several
>   times already (#229357) to let the dpkg-source know that the package 
> supports
>   the new source format (instead of using a dedicated field)

And afaics it's not really something you can do automatically (ie, you
need a human to decide if you want to use the "experimental-featureset"
branch on a per-package basis), so shouldn't need any new options,
afaics...

> I plan to write code in that direction:
> - add the API required for wig&pen
> - make dpkg-source be able to generate wig&pen source package
> - then add some scripts that use the wig&pen API to generate source
>   packages from a VCS directory
> Comments are welcome.

So far, wig&pen has objectively failed as a source format; please let
the git/bzr/etc format succeed or fail on its own merits, without tying
it to a wig&pen resurrection attempt...

Cheers,
aj



signature.asc
Description: Digital signature

Re: dpkg-source's future and relation with VCS

[Raphael Hertzog]

Hi,

On Mon, 11 Feb 2008, Frank Lichtenheld wrote:
> For me this sentence is the essence of your mail: That you dislike
> Joey's idea since it includes the VCS in the source package itself and
> would prefer that we worked on creating a solution on top of wig&pen
> instead.
> 
> Do I understand that correctly?

No. I don't dislike it at all, I do like distributed VCS and the workflow
and I believe that when upstream is using a DVCS, the $vcs.tar.gz is a
really nice approach.

However I'm also convinced that:
- a source package should be unpackable without a VCS. This means that
  somehow it should contain a checkout that can be extracted with basic
  tools. [1]
- it will take several years until we can standardize on VCS-based source
  package whereas the switch to wig&pen can be quick. In the mean time, a
  nice intermediary solution is to generate the wig&pen source package
  from the VCS.

[1] to solve this for the git case I wonder if we can take files from the
checkout and copy them (temporarily) in the .git/objects/ directory so
that we don't duplicate files and get other packs based on those
pre-existing objects ?

> > I plan to write code in that direction:
> > - clean up dpkg-source and move code in a Dpkg::Source API
> 
> We should definetly get started doing this since it will be benefical
> for any proposal.

Yes.

> > - add the API required for wig&pen
> > - make dpkg-source be able to generate wig&pen source package
> > - then add some scripts that use the wig&pen API to generate source
> >   packages from a VCS directory
> 
> The other steps will probably require us getting some common agreement
> on the direction we want to go.

Indeed. 

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-source's future and relation with VCS

[Frank Lichtenheld]

On Mon, Feb 11, 2008 at 12:48:19PM +0100, Raphael Hertzog wrote:
[...]
> But the complicated part comes when we try to think of interactions
> between VCS and source package format. I'd like to keep the (default)
> source package format mostly VCS agnostic but I'd like the source
> package to be easily generated from a VCS. The idea is the following:

For me this sentence is the essence of your mail: That you dislike
Joey's idea since it includes the VCS in the source package itself and
would prefer that we worked on creating a solution on top of wig&pen
instead.

Do I understand that correctly?

[...]
> 
> I plan to write code in that direction:
> - clean up dpkg-source and move code in a Dpkg::Source API

We should definetly get started doing this since it will be benefical
for any proposal.

> - add the API required for wig&pen
> - make dpkg-source be able to generate wig&pen source package
> - then add some scripts that use the wig&pen API to generate source
>   packages from a VCS directory

The other steps will probably require us getting some common agreement
on the direction we want to go.

Gruesse,
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]