etcupdate and postinstall: make "-s src" compulsory
Alan Barrett
was specified. I believe that this is not useful, because:
* many people keep their sources elsewhere than /usr/src;
* etcupdate, when given a source directory, attempts to run "make
distribution" in ${SRCDIR}/etc, and this often fails. Fixing the
make failures is non trivial, and I really don't care about fixing
them because I always recommend that people should use "etcupdate -s
etc.tgz".
So, I'd like to make it an error to run postinstall or etcupdate without
giving a "-s" arg. People can still use "-s /usr/src" to get the
existing (IMHO broken) behaviour.
--apb (Alan Barrett)
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Sverre Froyen
> So, I'd like to make it an error to run postinstall or etcupdate without
> giving a "-s" arg. People can still use "-s /usr/src" to get the
> existing (IMHO broken) behaviour.
I have no problem with requiring the -s arg. I would, however, like to be
able to run etcupdate after a "build distribution", i.e., without the extra
step of "build sets". This would require solving the etc make issue.
On a slightly similar note, I think it would be nice if etcupdate had an
option to completely ignore files where a locally modified installed version
had the same RCS version as the distribution version. Used with the -a
option, such an option would prevent most of the prompts to install new
files. If this sounds useful to others, I could take a stab at it. Comments?
Sverre
Alan Barrett
> Alan Barrett <a...@cequrux.com> suggests
> > So, I'd like to make it an error to run postinstall or etcupdate without
> > giving a "-s" arg. People can still use "-s /usr/src" to get the
> > existing (IMHO broken) behaviour.
>
> I have no problem with requiring the -s arg. I would, however, like to be
> able to run etcupdate after a "build distribution", i.e., without the extra
> step of "build sets". This would require solving the etc make issue.
If you mean really and truly solving the etc make issue, then I think
that's unrealistic. How can etcupdate possibly know what args passed to
build.sh might have affected the contents of certain files?
If you mean simply making the problem no worse than usual, by solving the
most obvious current issue with atf-run.hooks, then I am in the process
of trying to do that. I only realised today that there was a problem.
> On a slightly similar note, I think it would be nice if etcupdate
> had an option to completely ignore files where a locally modified
> installed version had the same RCS version as the distribution
> version.
This sounds like the etcupdate "-l" option.
--apb (Alan Barrett)
Alan Barrett
> etcupdate and postinstall both behave, by default, as if "-s /usr/src"
> was specified. I believe that this is not useful, because:
>
> * many people keep their sources elsewhere than /usr/src;
>
> * etcupdate, when given a source directory, attempts to run "make
> distribution" in ${SRCDIR}/etc, and this often fails. Fixing the
> make failures is non trivial, and I really don't care about fixing
> them because I always recommend that people should use "etcupdate -s
> etc.tgz".
>
> So, I'd like to make it an error to run postinstall or etcupdate without
> giving a "-s" arg. People can still use "-s /usr/src" to get the
> existing (IMHO broken) behaviour.
There were no objections to that suggestion, so I'd like to implement it
soon.
Christos Zoulas
Alan Barrett <a...@cequrux.com> wrote:
>On Thu, 20 Dec 2007, Alan Barrett wrote:
>> etcupdate and postinstall both behave, by default, as if "-s /usr/src"
>> was specified. I believe that this is not useful, because:
>>
>> * many people keep their sources elsewhere than /usr/src;
>>
>> * etcupdate, when given a source directory, attempts to run "make
>> distribution" in ${SRCDIR}/etc, and this often fails. Fixing the
>> make failures is non trivial, and I really don't care about fixing
>> them because I always recommend that people should use "etcupdate -s
>> etc.tgz".
>>
>> So, I'd like to make it an error to run postinstall or etcupdate without
>> giving a "-s" arg. People can still use "-s /usr/src" to get the
>> existing (IMHO broken) behaviour.
>
>There were no objections to that suggestion, so I'd like to implement it
>soon.
I use /usr/src and I am perfectly happy. Why break it?
christos
Quentin Garnier
> In article <2008101811...@apb-laptoy.apb.alt.za>,
> Alan Barrett <a...@cequrux.com> wrote:
> >> etcupdate and postinstall both behave, by default, as if "-s /usr/src"
> >> was specified. I believe that this is not useful, because:
> >>
> >> * many people keep their sources elsewhere than /usr/src;
> >>
> >> * etcupdate, when given a source directory, attempts to run "make
> >> distribution" in ${SRCDIR}/etc, and this often fails. Fixing the
> >> make failures is non trivial, and I really don't care about fixing
> >> them because I always recommend that people should use "etcupdate -s
> >> etc.tgz".
> >>
> >> So, I'd like to make it an error to run postinstall or etcupdate without
> >> giving a "-s" arg. People can still use "-s /usr/src" to get the
> >> existing (IMHO broken) behaviour.
> >
> >There were no objections to that suggestion, so I'd like to implement it
> >soon.
>
Because it won't do the right thing when you do build.sh -V MKCRAP=no.
The point is not to break it, it is to make sure people who use it know
what they're doing.
--
Quentin Garnier - cu...@cubidou.net - cu...@NetBSD.org
"See the look on my face from staying too long in one place
[...] every time the morning breaks I know I'm closer to falling"
KT Tunstall, Saving My Face, Drastic Fantastic, 2007.
Alan Barrett
> >> * many people keep their sources elsewhere than /usr/src;
> >>
> >> * etcupdate, when given a source directory, attempts to run "make
> >> distribution" in ${SRCDIR}/etc, and this often fails. Fixing the
> >> make failures is non trivial, and I really don't care about fixing
> >> them because I always recommend that people should use "etcupdate -s
> >> etc.tgz".
> >>
> >> So, I'd like to make it an error to run postinstall or etcupdate without
> >> giving a "-s" arg. People can still use "-s /usr/src" to get the
> >> existing (IMHO broken) behaviour.
> >
> >There were no objections to that suggestion, so I'd like to implement it
> >soon.
>
The default behaviout has always been broken. It runs "make
distribution" in the etc subdirectory, and there have been many problem
reports due to this "make distribution" using options different from
those in effect when the rest of the tree is built. For example, if
obj dirs are used in one case but not the other, then there have been
problems when etcupdate tries to build MAKEDEV.
Because the default behaviour is broken, I don't want it to be the
default (though it would continue to be available if you explicitly ask
for "-s /usr/src").
Christos Zoulas
-- Subject: Re: etcupdate and postinstall: make "-s src" compulsory
| Because it won't do the right thing when you do build.sh -V MKCRAP=3Dno.
| The point is not to break it, it is to make sure people who use it know
| what they're doing.
I still don't undestand how it breaks. Is it because the src tree
is not there?
christos
Johnny Billquist
> In article <2008101811...@apb-laptoy.apb.alt.za>,
> Alan Barrett <a...@cequrux.com> wrote:
>>> etcupdate and postinstall both behave, by default, as if "-s /usr/src"
>>> was specified. I believe that this is not useful, because:
>>>
>>> * many people keep their sources elsewhere than /usr/src;
>>>
>>> * etcupdate, when given a source directory, attempts to run "make
>>> distribution" in ${SRCDIR}/etc, and this often fails. Fixing the
>>> make failures is non trivial, and I really don't care about fixing
>>> them because I always recommend that people should use "etcupdate -s
>>> etc.tgz".
>>>
>>> So, I'd like to make it an error to run postinstall or etcupdate without
>>> giving a "-s" arg. People can still use "-s /usr/src" to get the
>>> existing (IMHO broken) behaviour.
>> There were no objections to that suggestion, so I'd like to implement it
>> soon.
>
I'll have to agree with Christos here. Why break it?
The first reason is irrelevant, as far as I can see.
The second can't hardly be a reason either.
Johnny
Eric Haszlakiewicz
> Christos Zoulas wrote:
> >>On Thu, 20 Dec 2007, Alan Barrett wrote:
> >>> * many people keep their sources elsewhere than /usr/src;
> >>>
> >>> * etcupdate, when given a source directory, attempts to run "make
> >>> distribution" in ${SRCDIR}/etc, and this often fails. Fixing the
> >>> make failures is non trivial, and I really don't care about fixing
> >>> them because I always recommend that people should use "etcupdate -s
> >>> etc.tgz".
> >
>
> I'll have to agree with Christos here. Why break it?
> The first reason is irrelevant, as far as I can see.
> The second can't hardly be a reason either.
I'd say that part of the reason would be to encourage people to use
the final output of a build when installing, rather than poking into
the source tree. For a while now we've been discouraging people from
running a "make install" directly into a DESTDIR of /, and if you're
upgrading from tarballs it feels wrong to have the default process
require you to have a copy of the sources.
eric
Johnny Billquist
> On Sat, Oct 18, 2008 at 08:36:35PM +0200, Johnny Billquist wrote:
>> Christos Zoulas wrote:
>>>> On Thu, 20 Dec 2007, Alan Barrett wrote:
>>>>> * many people keep their sources elsewhere than /usr/src;
>>>>>
>>>>> * etcupdate, when given a source directory, attempts to run "make
>>>>> distribution" in ${SRCDIR}/etc, and this often fails. Fixing the
>>>>> make failures is non trivial, and I really don't care about fixing
>>>>> them because I always recommend that people should use "etcupdate -s
>>>>> etc.tgz".
>>> I use /usr/src and I am perfectly happy. Why break it?
>> I'll have to agree with Christos here. Why break it?
>> The first reason is irrelevant, as far as I can see.
>> The second can't hardly be a reason either.
>
> I'd say that part of the reason would be to encourage people to use
> the final output of a build when installing, rather than poking into
> the source tree. For a while now we've been discouraging people from
> running a "make install" directly into a DESTDIR of /, and if you're
> upgrading from tarballs it feels wrong to have the default process
> require you to have a copy of the sources.
Okay. So the recommendation is to use -s, and the proposed changes don't
affect any of that. You're just annoyed that it actually will try to do
something if you don't give a -s?
The fact that for the people and situations referred to above, the
default won't work seems to me to make it pretty harmless. And for
people who actually do use stuff the "old" way, it has always worked,
and continues to work, and you just want to mess with them, is a good
reason?
Oh well. I really should give up. After all, I've given up on using
NetBSD on my machines, as it never works anyway nowadays.
Johnny
Eric Haszlakiewicz
> Okay. So the recommendation is to use -s, and the proposed changes don't
> affect any of that. You're just annoyed that it actually will try to do
> something if you don't give a -s?
> The fact that for the people and situations referred to above, the
> default won't work seems to me to make it pretty harmless. And for
> people who actually do use stuff the "old" way, it has always worked,
> and continues to work, and you just want to mess with them, is a good
> reason?
I'm not entirely sure it's harmless, although I've always been careful enough
to remember to pass an appropriate -s flag. On the machine I build on
/usr/src is definitely NOT the right source tree for updating / against,
so if I were to leave off the -s option I don't think I'd end up with the
correct updates.
Then again, the way I've got things set up probably isn't very common.
Greg Troxel
Eric Haszlakiewicz <e...@nimenees.com> writes:
> I'm not entirely sure it's harmless, although I've always been careful
> enough to remember to pass an appropriate -s flag. On the machine I
> build on /usr/src is definitely NOT the right source tree for updating
> / against, so if I were to leave off the -s option I don't think I'd
> end up with the correct updates. Then again, the way I've got things
> set up probably isn't very common.
I would say that your setup is broken; /usr/src should be either the
sources for the running system or outright missing. I usually have
sources someplace else and symlink /usr/src to them. Other things could
look in /usr/src, including I think pkgsrc builds of kernel modules.