* From: Jordan K. Hubbard j...@zippy.cdrom.com
* As long as that directory is not /var/db/pkg, where I put my package
* information, I agree that it doesn't matter either. :-)
Ok. I'll move it out then.
* I'm not sure that this is a solution so much as a band-aid, however.
Of course.
The name of the directory where it resides doesn't matter. It's not a
As long as that directory is not /var/db/pkg, where I put my package
information, I agree that it doesn't matter either. :-)
The same situation arises whether the version info is in /var/db/pkg
or /some/other/place. It
* From: Jordan K. Hubbard j...@zippy.cdrom.com
*
* Committing /var/db/pkg to mtree was fine, it probably should have been
* there to begin with. Sticking things into it outside of pkg_add,
* however, is evil. pkg_add owns this directory and every time we've
* tried to go behind its back,
[ Yes, I'm sticking my nose in where it probably doesn't belong and
should get chopped off for it. It's a hobby ;]
On Thu, Apr 01, 1999 at 02:36:14AM -0800, a little birdie told me
that Satoshi - the Wraith - Asami remarked
The same situation arises whether the version info is in /var/db/pkg
* From: Matthew D. Fuller fulle...@futuresouth.com
* [ Yes, I'm sticking my nose in where it probably doesn't belong and
* should get chopped off for it. It's a hobby ;]
Don't worry, I enjoy chopping off noses. :)
* On Thu, Apr 01, 1999 at 02:36:14AM -0800, a little birdie told me
* that
I have to agree that the problem is real.
However, let me point out that a one identifier solution is
very short sided.
There are two distinct environments to be considered.
The HOST environment and the TARGET environment.
For convience, we should also consider a TOOLSET
environment which is a
On Thu, 1 Apr 1999, Richard Wackerbarth wrote:
I have to agree that the problem is real.
However, let me point out that a one identifier solution is
very short sided.
There are two distinct environments to be considered.
The HOST environment and the TARGET environment.
For convience, we
* From: Richard Wackerbarth r...@dataplex.net
* I have to agree that the problem is real.
* However, let me point out that a one identifier solution is
* very short sided.
sighted :
* There are two distinct environments to be considered.
* The HOST environment and the TARGET
On Thu, 1 Apr 1999, Chuck Robey wrote:
On Thu, 1 Apr 1999, Richard Wackerbarth wrote:
The natural tag for the TARGET would be in
/usr/src/include. However, I can see some problems with this for
the ports tree.
Richard, don't forget that having /usr/src isn't required to build
ports.
In message 19990401052839.d11...@futuresouth.com, Matthew D. Fuller wrote:
} [ Yes, I'm sticking my nose in where it probably doesn't belong and
} should get chopped off for it. It's a hobby ;]
}
} On Thu, Apr 01, 1999 at 02:36:14AM -0800, a little birdie told me
} that Satoshi - the Wraith -
On Thu, 1 Apr 1999, Satoshi - the Wraith - Asami wrote:
* From: Richard Wackerbarth r...@dataplex.net
* very short sided.
sighted :
Yes, a slight transfer error between my brain and 'sendmail'.
* There are two distinct environments to be considered.
* The HOST
On Thu, 1 Apr 1999, Richard Wackerbarth wrote:
Richard, don't forget that having /usr/src isn't required to build
ports.
I don't think that I did forget. I explicitly reference that situation.
The real solution (re the TARGET) has to depend on something that the USER
sets for a
On Thu, 1 Apr 1999, Chuck Robey wrote:
On Thu, 1 Apr 1999, Richard Wackerbarth wrote:
Your statement Nobody said cross compilation is easy :-)
By this smiley, I mean to infer that it is far from easy.
you're the ONLY one to demand it. OK, maybe even demand is wrong
If you were talking
On Wed, 31 Mar 1999, Jordan K. Hubbard wrote:
I think this entire thing is a massive botch and needs to be removed
as a bad idea ASAP.
I think that's jumping to conclusions a little too quickly.
Jordan, we are eliminating a LOT more future PRs and FAQs by using this
method. A few permission
a LOT more future PRs and FAQs by using this
method. A few permission and installation oversights (no software can ever
be tested on every possible instance.) should not constitute removal of
the whole idea.
At minimum, the implementation is off...
What /var/db/pkg/.mkversion is tracking w
corrected it so if you cvsup again and make world again
(actually just make install in src/share/mk), all will be well. As
a workaround, echo 19990328 /var/db/pkg/.mkversion will work
equally fine.
Just a side note; this new file breaks pkg_info. I've appended a simple
patch below; somebody
a directory or not
* if (chdir(log_dir) == FAIL) {
* -warnx(can't change directory to '%s'!, log_dir);
* -return 1;
* +if (strcmp(log_dir, /var/db/pkg/.mkversion) != 0) {
* +warnx(can't change directory to '%s'!, log_dir);
* +return 1
On Wed, Mar 31, 1999 at 09:56:07AM +0100, Dom Mitchell wrote:
On 30 March 1999, Satoshi Asami proclaimed:
Just a side note; this new file breaks pkg_info. I've appended a simple
patch below; somebody ought to do something better for the version in
the src tree.
Yep, this definitely
and make world again
(actually just make install in src/share/mk), all will be well. As
a workaround, echo 19990328 /var/db/pkg/.mkversion will work
equally fine.
CVSup'd RELENG_2_2 this afternoon, did make install in
/usr/src/share/mk. Still no good.
-crl
--
Chad R. Larson (CRL15
* From: Chad R. Larson c...@freebie.dcfinc.com
* CVSup'd RELENG_2_2 this afternoon, did make install in
* /usr/src/share/mk. Still no good.
Oh yes, RELENG_2_2. Sorry, fixed.
-W
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Now that make world do something in /var/db/pkg, shouldn't /var/db/pkg
be added to the mtree list for 3.1-STABLE and current? Otherwise a
make release will break and also a make world if you haven't installed
any packages yet.
I think this entire thing is a massive botch and needs to be
Committing /var/db/pkg to mtree was fine, it probably should have been
there to begin with. Sticking things into it outside of pkg_add,
however, is evil. pkg_add owns this directory and every time we've
tried to go behind its back, so to speak, we've been raped for it.
The whole mess with
Sorry to bud in... but shouldn't /var/db/pkg be only used for package
admin purpouses and only for that. Otherwise things get sloppy if one
needs to have a .mkversion shouldn't it be in /etc and automatically
generated upon bootup from the kernel version number or if the file is
used to assetain
world again
(actually just make install in src/share/mk), all will be well. As
a workaround, echo 19990328 /var/db/pkg/.mkversion will work
equally fine.
Sorry for the trouble,
-W
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
/.mkversion
cannot create /var/db/pkg/.mkversion: directory nonexistent
*** Error code 2
Stop.
*** Error code 1
/var/db/pkg doesn't exist in the make release area... I don't
know if it should or not... Thanks for any insight...
-John
To Unsubscribe: send mail to majord...@freebsd.org
and make world again
(actually just make install in src/share/mk), all will be well. As
a workaround, echo 19990328 /var/db/pkg/.mkversion will work
equally fine.
Now that make world do something in /var/db/pkg, shouldn't /var/db/pkg
be added to the mtree list for 3.1-STABLE and current? Otherwise
I have since corrected it so if you cvsup again and make world again
(actually just make install in src/share/mk), all will be well. As
a workaround, echo 19990328 /var/db/pkg/.mkversion will work
equally fine.
Now that make world do something in /var/db/pkg, shouldn't /var/db/pkg
* From: John Hay j...@mikom.csir.co.za
* Now that make world do something in /var/db/pkg, shouldn't /var/db/pkg
* be added to the mtree list for 3.1-STABLE and current? Otherwise a
* make release will break and also a make world if you haven't installed
* any packages yet.
Oh, so *that* was
28 matches
Mail list logo
