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