| Colin Watson | |||||
|
Subscribe
Flavours |
Mon, 23 Jun 2008 Christoph:
That's because $ perl -le 'print "yoo" if (1 + 1) =~ /3/' perlop(1) has a useful table of precedence. Thu, 29 Nov 2007Erich: I do sometimes wonder why we don't relax the definition of "safe" upgrades to include installing new packages but still not removing old ones. I know that many of my uses of dist-upgrade are just for when something grows a new dependency that I didn't previously have installed. (Of course this wouldn't always help as it wouldn't account for a new dependency that conflicted with an old dependency, but never mind. It would certainly do wonders for the metapackage case.) Sat, 23 Dec 2006
Joey has been
campaigning
for a while to get everything in the archive changed to depend on
Recently it occurred to me that we didn't necessarily have to do it that
way round. In a bout of late-night hacking while staying awake to look after
a sick child (he seems mostly OK now, although the rushed trip to the
hospital earlier was a bit on the nerve-wracking side), I've shuffled things
around in the cdebconf package so that it no longer has any file conflicts
with debconf or debconf-doc, and changed the debconf confmodule to fire up
the cdebconf frontend rather than its own if the
DEBCONF_USE_CDEBCONF environment variable is non-empty. (The
details of this may change before it actually gets uploaded, as I'd like to
get Joey to look it over and approve it first.) This allows you to install
cdebconf, set that environment variable, and play around with cdebconf with
relative ease; when we come to switch to cdebconf for real, instead of a
huge conflicting mess that apt will probably have trouble resolving, it'll
just be a matter of changing a couple of lines in
Of course, don't expect cdebconf to be a complete working replacement for debconf just yet; if you try using it for a dist-upgrade run it'll fall over. Due to its d-i heritage, it doesn't yet load templates automatically; that has to be done by hand. Frontend names differ from debconf's, which will need some migration code. At the moment it can only handle UTF-8 templates, which are mandated in the installer but only optional in the rest of the system. It doesn't have all of debconf's rich array of database modules. I haven't adapted the Perl or Python confmodules yet. The list goes on. However, I think we at least stand a chance of getting a handle on the problem now. (I'll post this article to debian-devel once the changes have been reviewed and uploaded.) Tue, 03 Jan 2006Sometimes following up on a bug takes you a lot further than you expected. Debian bug #337041 looked like it was going to be fairly straightforward once I upgraded coreutils to figure out what the new IUTF8 flag actually did, since the SSH2 protocol already supports transferring termios flags around. Unfortunately, since IUTF8 is relatively new, it doesn't have a number assigned in the draft connection protocol. Moreover, that Internet-Draft is in the last stages before becoming an RFC and can't be modified any more, and it doesn't include any facility for private-use extensions. D'oh. To add further complication, since IUTF8 is Linux-specific, it's not hard to imagine that some other OS might introduce something with the same name but subtly different semantics, and so the SSH protocols can't just defer to POSIX for the definition but instead have to spell out exactly what they mean. As a result of all of this, it looks like the best way to make progress might be for me to write an I-D myself that creates a channel extension to set or clear IUTF8, and attempt to enlist support from some upstream implementors. I didn't expect bug triage to lead me into the Internet standardisation process quite so quickly! |
||||