[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#491723: Status.net Debian Package



Hi,

First of all thanks for taking a look at the package!

On 27/10/10 00:54, Brenda Wallace wrote:
> The previous repo was a clone of the main project, plus debian folder+Makefile.
> If you have a process for managing merging fixed, then no problem.
> you're going to put tarballs over top?

I'm not sure if this is what you mean by "tarballs", but I forgot to
mention one thing: I never really understood the need for pristine-tar
in git-buildpackage, so I left it out. AFAICT you can accomplish the
exact same thing by exporting the upstream/X.Y.Z branch, but please let
me know if there's actually missing functionality. Should be pretty easy
to include the pristine-tars later on.

I also didn't see any problem with the merging from upstream, but
probably because I'm not working on a clone and instead using a simple
git-import-orig to directly merge everything from the released tarball
into the repo. I believe this is the sanest way to keep the debian repo,
i.e. logically separate from the upstream repo. We just perform "merges"
- actually imports - from upstream when there's a release, so debian
packaging work and upstream development work have well defined boundaries.

> 
> Working with apache+mysql outta the deb would be enough for first
> iteration. I'm a big lighttpd fan so i'll give it a test.

Thanks!
I personally use lighty too, but I just didn't get around to testing it yet.

> 
> Having none of the daemons set up is reasonable. They become necessary
> when wanting to scale and/or add the fancy features.
> 

Perfect. This makes our lives significantly easier! :)

> 
> I think you want to do a make clean, and then remove some compiled
> files from the git repo

As mentioned above, I believe the best way to manage the debian repo is
by importing upstream releases, keeping them as close as possible to the
upstream state and keeping changes inside the /debian dir as much as
possible. Specially since this makes for a more straightforward
structure for people who want to work with or build the package directly
from the orig.tar.gz + debian.tar.gz, instead of from the repo. This has
the not-so-neat side-effect that some "useless" files which are included
in the upstream tarball have to remain in the repo.

I obviously don't mean to dictate other people's workflow and certainly
don't want to alienate anyone from helping out with the packaging work,
but the practicalities from a debian-maintainer perspective IMHO
overweight the small size increase in the repo.


Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]



Reply to: