Re: New fvwm95 into unstable
Manoj Srivastava <firstname.lastname@example.org> writes:
> >>"Daniel" == Daniel Martin at cush <email@example.com> writes:
> Daniel> I'd also recommend that people upgrading directly from bo
> Daniel> upgrade to this package instead of the one in frozen, as this
> Daniel> package's preinst cleans up the old bo config. files (the name
> Daniel> of the config. files changed), but only if it can determine
> Daniel> that they're unmodified, which can only happen if the
> Daniel> previously installed version was the bo one.
> Unfortunately, that is not an option for many people, Think
> CD-ROM. Why can't this improvement be made to frozen as well? (just
> the preinst, not any upstream changes?)
I suppose I could package up an fvwm95 whose only difference over the
version currently in frozen would be the enhanced preinst. What I'd
really like is to put the -3 fvwm95 that I just uploaded into frozen;
however, I'm loathe to put anything into frozen as a new developer
unless I have some kind of consensus behind me - when I posted near
the end of last week to debian-private and then debian-devel about
whether I could put -3 into frozen, I got no response and took this
to mean I had no consensus backing me.
I suppose I should also point out at some point that making this
change is not as simple as using the -3 preinst in the current -2
package, since the configuration file name changed from
system.fvwm95rc-menu in -2 to system.fvwm95rc in -3 due to other
improvements. Not that it still wouldn't be easy to make a preinst
that does the right thing, it's still not just trivial.
That said, however, I'm amenable to doing something like this, because
I dislike the idea of leaving people who get hamm off CDs or who don't
follow -changes lists with obsolete files on their system.
Now, what's most desirable in this case?
1) Upload a new fvwm95_2.0.43b-3 that is essentially the same as
fvwm95_2.0.43b-2 but with the "Distribution: " header set to frozen
and a better preinst? Would this wipe out the fvwm95_2.0.43b-3 in
slink, or would something be left in a screwed state?
2) Petition someone to have the -3 fvwm95 moved into frozen? (Again,
this is my preferred course of action, but I'm treading on uncertain
3) Create a fvwm95_2.0.43b-4 that is essentailly -2 with a better
preinst and "Distribution: frozen", and a -5 with
"Distribution: unstable" that is essentially identical to the
currently existing fvwm95_2.0.43b-3?
(For those of you following at home who don't understand why
fvwm95_2.0.43b-3 wasn't put into frozen in the first place, let me
attempt to explain by saying that -3 as compared to -2 has a patch
which closes some annoying bugs and allows the configuration to be
reworked - -3 handles configuration files the way fvwm2 does, which is
completely different from (and much saner than) the old (<= 2.0.43b-2)
way of handling fvwm95 configuration. This change could be considered
as large as an upstream change introducing new features, and even
though I've tested it and it runs fine on my system, I still didn't
want to put it into frozen because of this.)
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com