Re: Bug#282067: yes!
On Mon, 2004-12-20 at 10:53 +0100, martin f krafft wrote:
> also sprach Gergely Nagy <algernon@bonehunter.rulez.org> [2004.12.18.1241 +0100]:
> > For a transitional period, I suggest you create $HOME/etc, move
> > your dotfiles there and symlink them back. Then try to put your
> > $HOME in CVS or use it on a system that still thinks that the
> > status-quo is perfectly fine.
>
> I have been doing so for years. What am I to watch out for?
CVS doesn't like symlinks. So if I have ~/etc/yada.conf, and ~/.yadarc
is a symlink to that, CVS will probably think they are two different
files.
I can solve that with .cvsignore, but I wouldn't be too happy with
keeping yet-another-file up-to-date just so my setup remains working.
About using it on systems that do not approve of the migration: one has
to symlink files back, which gets you a cluttered $HOME AND an ~/etc.
Worst of both worlds, thankyouverymuch.
> > Inode quotas. The number of files (that includes directories and
> > symlinks) is limited, and for my work there, I need quite a few
> > files, so I'm already near my limit. Were I forced to place
> > a hundred symlinks, I'd overrun my quota. That means, that either
> > I can't work on that box, or I need to change my habits, and stop
> > managing my $HOME in CVS.
>
> I do not consider that an argument against my proposal, rather an
> argument for your system administrators to upgrade hardware and
> policy.
Not an option. The system has been in used for as far back as I can
remember and it works flawlessly, apart from this little annoyance I can
handle fine right now. There's no reason to upgrade neither hardware,
nor software. Not to mention that would cost more than the owners are
willing to spend, for no financial gain.
> We are not kicking KDE 3 out of Debian because I still have some
> systems with 200 Mb harddrives.
Nor do we have to install it at all, while dotfile migration wouldn't be
a choice, were your proposal accepted. Installing KDE or not, is a
choice.
> > > As another post suggested, the standard, if it's implemented, should be
> > > managed on a package-by-package basis. Which if ported back upstream
> > > means that cross-distro compatibility should be maximized. Not wholly
> > > problem-free, but headed there.
> >
> > It should be done upstream first, if done at all. And in such a way,
> > that the old location is searched first, then the new one.
>
> You are failing to acknowledge Debian's position wrt to innovation.
It's not innovation, it's a silly way to break existing practice for no
good reason. If you want, you can migrate your dotfiles anywhere you
want, and you can do that now, without any kind of policy. One can even
write an LD_PRELOAD-able shared library that intercepts open() calls,
and if it finds that the program is trying to open a dotfile in $HOME,
redirect it to ~/etc or something like that. That way it becomes quite
painless to do a migration on your own box, without breaking other
peoples setups that have worked fine during the last decade or so.
Or you can patch each program... or there are a thousand ways to move
dotfiles way from raw $HOME to a subdirectory, right now, without any
kind of policy, for your own boxes. And then everyone is happy.
> Upstream will change after the FHS changed. The FHS will change
> after Debian showed them the benefits. So Debian has to work on it
> (possibly with upstream).
I see no benefit of making this into any kind of standard. $HOME should
be a business of the user, one should be (and to an extent, is) able to
structure it the way he wants. It's my personal area, just leave it
alone.
Furthermore, as others noted in the thread, FHS is, or should, be able
to document existing practice - or when there are multiple alternative
implementations, choose one and document that. It should not intrude
into areas it has no business with.
> also sprach Gergely Nagy <algernon@bonehunter.rulez.org> [2004.12.18.1236 +0100]:
> > Especially if that's only on Debian, and the rest of the world is
> > still putting stuff into $HOME... (that is, if there's a way for
> > migration, it needs to start with persuading upstream authors that
> > it needs to be done. Until a considerable amount of software
> > supports both locations, there's no chance the opposing voices
> > will go silent)
>
> Catch 22. It's never going to happen unless we do it.
Yes. It won't, unless you can persuade a large number of developers that
what they've been doing wrt dotfiles in the past few years was a bad
idea to begin with. I do not see any chance of success, to be honest.
> So I urge you to please stop holding on to the "it's never been done
> before" and "but it works, why change it" excuses and think and
> discuss about the technical pros and cons instead.
I mentioned quite a few technical cons, and fail to see any pros. If one
wants, he can migrate $HOME right now, without forcing it all over the
world.
Anyway, I'll repeat some concerns I have:
First of all, there must be a migration path: for a limited amount of
time, software that is migrating its configuration file needs to ease
this migration. There are multiple ways to help the user with this:
- The program can read search both locations.
Pros: Seems to be the smoothest and doesn't get in ones way if works
correctly.
Cons: Complicates code, and easy to screw it up. Then, what happens if
both files exist and they provide conflicting settings? You can't choose
automatically, so you have to ask the user, or quit with an error.
Neither is desirable, especially if the program can be called from a
script, which might run from cron, for example.
Due to this possible - and likely, in my opinion - conflict problem,
this solution is out.
- The program searches the new location only.
Pros: The easiest way, doesn't present the conflict problem present when
searching both locations.
Cons: Not backward compatible, at all. This solution is out.
- Move the config file automatically.
Pros: Provides an easy migration path, and if nothing breaks, serves the
user right.
Cons: Breaks $HOME-in-CVS badly. Since deliberate breaking of ones setup
should not be considered good behaviour, this solution is out too.
- Symlink the config file automatically: this would either move the
configfile to the new location and symlink it back to the old one, or
the other way around.
Pros: Easy migration if nothing breaks and does not break $HOME-in-CVS
if done right.
Cons: Clutters $HOME even more than it was before, since the old file
must remain in place for $HOME-in-CVS to remain working reliably. And
many users will not notice the migration, will end up with a more
cluttered home, and the purpose is defeated. This is out too..
At the moment, I can't think of any more solutions. I think we can agree
that autmatic movement is not possible, without introducing major
breakage in more complicated setups. And when manual intervention is
required, that will only cause annoyance and confusion. When dealing
with files in /etc, and you move a file, that annoys the system
administrator. Users don't care. When you move files around in a users
private space, his precious $HOME, and require them to manually fiddle
with the movement at a few times, they'll get very annoyed. I happen to
know that from experience. Once, we had a smaller computer farm, where
we had a quite strict company policy that set some policies about $HOME
too (actually, only a few files in $HOME). Then, at one point, we
figured that the policy is flawed, and one file would be better put in a
different place. We tried our best to make the migration smooth, but in
order to ensure that nothing ever breaks, there had to be a warning
issued when automatic movement simply couldn't work. ALL our users
received the warning, and were so enraged, that the policy had to be
reverted to the original, and remained so until today, as far as I know.
Then, there is the problem of interoperability. You mentioned that
unless someone (Debian, in this case) starts to do it, migration will
never happen. However, as soon as Debian starts the migration, but some
common systems don't, there will be problems. Let me outline them:
Until the migration is an ongoing effort, there will be times when on
Debian, the new version of the software is installed, which does the
migration in some way. It is a matter of time, and the dotfile will
likely move completeley, and be available in my $HOME at the new
location. Then, I log into a NetBSD system for example, update my $HOME
from CVS... and there problems start, as my dotfiles are nowhere to be
found! That is, not where the programs on that system would expect them
to be, because that operating system did not even start the migration
yet. The only work around I see for this, is when the compatibility code
stays there almost forever. That pretty much defeats the purpose.
To put it short: until only one system starts to migrate (with our
without upstream help), there will be interoperability problems, because
older versions of softwere will be in use for many years, even if they
have much newer and shinier versions.
> > > What's more important than raw implmentation is expressing a preference
> > > and getting applications developers to start following it. Everything
> > > else is bloviating.
> >
> > My preference (both as a user and upstream for a few small utilities) is
> > to leave everything as-is until I have more files in ~/etc than in plain
> > old $HOME.
>
> "men who say it cannot be done should not interrupt men doing it."
> -- old chinese proverb
So, do it on your own computers, and don't try to force it on others who
don't want it. You can do that right now, and no-one is stopping you.
I can go and propose that we move to application directories,
because /usr/bin is so cluttered I can't wade through it, but I will be
laughed at, I suppose (not suprising, it's a silly idea).
> I am not suggesting that ~/etc must happen. I am trying to argue for
> it. You have some valid arguments along the lines of "never touch
> a running system". If we would cling to that, there would be no
> innovation, and I would not see a point to releasing a new stable in
> the first place.
Innovation is all good, but when it is forced on me, it is not. There is
nothin stopping anyone to set up his home to use ~/etc, they can even
start persuading upstreams so programs start looking at both locations
(but then, see my concerns about that). But trying to force that on
those who are pretty happy with the status-quo, and fail to see what the
problem is with a few hundred hidden files one normally does not even
see.. that I do not get.
--
Gergely Nagy
Reply to: