Bug#311479: Nexuiz: status update?

Bruno Kleinert fuddl at gmx.de
Wed Jun 21 18:31:02 UTC 2006


This one time, at band camp, Alexander Schmehl wrote:
> Hi!
> 
> * Bruno Kleinert <fuddl at gmx.de> [060621 17:16]:
> 
> > after rtfm how to edit bug reports i noticed that you already modified
> > the itp ;) thanks!
> 
> You are welcome :)
> 
> > as upstream released another hotfix, i included it
> > (data20060614_weapontimingfix.pk3) into the nexuiz-data package. could
> > you upload the updated nexuiz-data package, please?
> > 
> > i also changed the nexuiz-prepare.sh script, it doesn't download the
> > hotfixes anymore, instead i stuffed the hotfixes uuencoded into the
> > diff.gz
> 
> Thinking about that, I'm not entirly sure, if this is the most elegant
> way.  And actually now I think the "hotfixed should be mentioned in
> version number" weren't a good idea, too.
> 
> If we put that stuff uudecoded in the diff.gz, it will have two major
> drawbacks:
> 1) the diff.gz will be become really huge and unreadable
> 2) We have (IMHO) ugly version numbers.
> 
> The "add hotfixes to orig.tar,gz, we create our own anyway" isn't a good
> idea either:  Every new hotfix requires a new upload including source.
> 
> 
> After thinking about it and asking my former AM about it, we got a new
> idea.
> 
> AFAIK those hotfixes are just files, which needed to be present, right?
> It won't happen, that such a file replaces an old file? (I assume so,
> please correct me, if I'm wrong.)
> 
> So:  Let's create a seperate package for hotfixes!
> 
> Benefit:
> - We neither need to upload new -data packages including source; we
>   don't need to touch -data at all
> - the diff.gz just contain the debian stuff and will stay small and
>   readable (I don't think we'll make it to e.g. a stable point release
>   or something similar, with the uudecode idea)
> 
> What we would need to do is to let -data depend on the -hotfix package.
> As soon as a new hotfix is released, we just add it to the hotfix
> package.  Everything is fine.
> 
> Drawback:
> - Should it ever happen, that we release a stable Debian distribution
>   without upstream having released a hotfix, yet, we would need an empty 
>   -hotfix package to satisfy -datas dependencies.
> 
> So I propose:
> - for now:
>   - wait till nexuiz get's through NEW
>   - if it is, upload the new hotfix in a seperate hotfix package
>   - if the hotfix package has gone through NEW
>   - upload new -data package depending on hotfix
> 
> - for the next Nexuiz release:
>   - create empty dummy hotfix package
>   - let -data depend on -hotfix
>   - upload them all together
>   - when new hotfixes are release, upload new hotfix package
> 
> 
> 
> 
> Yours sincerely,
>   Alexander
> 
> -- 
> http://www.netmeister.org/news/learn2quote.html
> http://www.catb.org/~esr/faqs/smart-questions.html

well, i didn't like the idea of messing up the diff.gz, either. on the
other hand i thought that the hotfixes don't belong into
the .orig.tar.gz...

i like the idea of having a nexuiz-hotfixes package to be flexible to
include one ore more hotfixes.

how about pulling the nexuiz-hoxfixes in, by creating a meta package,
that depends on the hotfixes? this way, users wouldn't need to download
the huge nexuiz-data package, because the only change was an added
dependency.

also this meta package could conflict with an old hotfix package, while
a newer -data package is already installed. i mention this, because the
hotfix package could break a newer -data package (files in the hotfix
package can easily override files in the -data package (this would
happen during the runtime of the nexuiz engine).

i'm not sure, if the meta-package isn't a shoot-in-the-foot. i could
imagine that conflicting on other packages might lead into problems
during an upgrade.

what do you think? if my idea is bs, i'll let -data depend on the
-hotfix package. 

also i contacted asked upstream, if they can tell me, when their
planned bugfix release will be out. perhaps they release it, before the
nexuiz package go through new - could save us the -hotfix package
atm! ;)

cheers, fuddl


-- 
Among elephants it's not considered cool nor in any good taste
to drain other elephants


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-games-devel/attachments/20060621/73397a77/signature.pgp


More information about the Pkg-games-devel mailing list