Re: [Fink-devel] Re: add in fink's docs, faq or help section

[Martin Costabel]

David R. Morrison wrote:

Thanks for the suggestion.  However, using any of the --force flags from
dpkg should really be a last resort, not something that people do very
often.  The problem is, when you do this you can leave your Fink installation
in an inconsistent state, and it may later be impossible to fix it again.


Unfortunately, we regularly have situations where --force-depends is 
necessary for upgrading. Anyone wanting to upgrade the kde packages had 
to do it. It was necessary for replacing xfree86 by Apple's X11. It will 
probably be necessary for upgrading to xfree86-4.3, and also for your 
new tetex.

I would prefer to have a paragraph in the docs that explains the command 
*and* the dangers over the present situation where more or less bored 
list members give the same advice over and over again, with less and 
less detailed explanations and occasional typos.

So I'm not actually in favor of adding this to the docs.  But I'm forwarding
your message (and my response) to the fink-devel mailing list in case
there are other opinions.


Just my ¤0.02

--
Martin




---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Re: Safety

[Martin Costabel]

Jeremy Erwin wrote:


On Saturday, February 1, 2003, at 10:48  PM, Ashley Yakeley wrote:

[]

I really see this as a simple sanity check on the dpkg. There are very
few packages that install outside of %p and no other package info files
need be affected.



jeremy@callisto:/sw/fink/dists/unstable/main/binary-darwin-powerpc/x11- 
system]$ fink validate xfree86-base_4.2.1.1-4_darwin-powerpc.deb
Validating .deb file xfree86-base_4.2.1.1-4_darwin-powerpc.deb...
Warning: File "/usr/" installed outside of /sw
Warning: File "/usr/X11R6/" installed outside of /sw
Warning: File "/usr/X11R6/bin/" installed outside of /sw
...

How many lines here? After how many lines do you stop looking at warnings?


etc.

I think that should suffice for validation.


The problem is that to be of any use, you would have to run this 
validation before installing the package, i.e. between the build phase 
of the deb and the install phase. For every package, every time. It 
wouldn't be enough that the package maintainer does it, as in the case 
we are discussing here, where there was no file outside the fink 
directory when I built the package, but there was one when Ashley built it.

How to do the validation? Ask the user about each file outside of /sw? 
For all 7790 of them in the case of xfree86? Or do it automatically by 
including a list of all files in the package description, as RPM or 
darwinports are doing it? And how to generate such a file list, 
automatically with the risk of bugs, or by hand as a punishment for 
packagers? Or just introduce a global yes/no permission for installing 
files outside of /sw? The latter would have caught the bug that started 
this thread, but what is the likelihood that such a thing will be 
reappear in a sufficiently similar way?

I don't yet see a possibility that is at the same time practical and useful.

--
Martin




---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Re: Safety

[Jeremy Erwin]

On Saturday, February 1, 2003, at 10:48  PM, Ashley Yakeley wrote:


In article <[EMAIL PROTECTED]>,
 Martin Costabel <[EMAIL PROTECTED]> wrote:




2. After the dpkg is built, fink should check it to make sure that  
all
the files are within %p (or within other directories somehow  
explicitly
mentioned in the .info file).

I would rather hope that in future the kind of error that happened  
here
will somehow get detected by human eyes before it can do much
destruction. I would regret it if my oversight were the reason for the
introduction of some heavy bureaucracy into fink that would be useful
only in extremely exceptional cases.

I really see this as a simple sanity check on the dpkg. There are very
few packages that install outside of %p and no other package info files
need be affected.



jeremy@callisto:/sw/fink/dists/unstable/main/binary-darwin-powerpc/x11- 
system]$ fink validate xfree86-base_4.2.1.1-4_darwin-powerpc.deb
Validating .deb file xfree86-base_4.2.1.1-4_darwin-powerpc.deb...
Warning: File "/usr/" installed outside of /sw
Warning: File "/usr/X11R6/" installed outside of /sw
Warning: File "/usr/X11R6/bin/" installed outside of /sw
...
etc.

I think that should suffice for validation.

Jeremy



---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Re: Safety

[Ashley Yakeley]

In article <[EMAIL PROTECTED]>,
 Corrin Lakeland <[EMAIL PROTECTED]> wrote:

> However, running fink without root really isn't that hard.

Yeah, I wrote a FAQ about that over a year ago. Of course you have an 
updated hack.

 Begin Forwarded Message 
Date:2001-10-18 21:08
From:Ashley Yakeley, [EMAIL PROTECTED]
To:  Fink-Developers List, [EMAIL PROTECTED]
Subject: [Fink-devel] Running Fink Non-Root FAQ

Running Fink Non-Root FAQ

1. What's that?
By hacking fink, you can get it to build packages non-root. You then 
install packages as root (or non-root, see #5).

2. Why might I want to do that?
Well, build scripts are long and complicated, and sometimes bad stuff 
can sneak in. I've discovered a number of bugs doing this, mostly 
scripts that install directly into the fink directory (%p), rather than 
the destination directory (%i). More specific reasons include:
a. you want to make sure your fink package doesn't do bad things at 
build time
b. you want to keep tight control of your system and don't trust build 
scripts not to do stuff like put files in the wrong place, muck about 
with NetInfo, etc.

3. Why might I want to not do that?
a. Some packages won't build, perhaps because they do a 'chown'. Mysql, 
for instance.
b. All your files will be installed owned by the building user, rather 
than root. This means the building user inappropriately has the right to 
fiddle with the files.
c. If you install packages as root, you can't auto-install dependent 
packages when building non-root.
d. It's a hack, it's not officially supported.

4. How do I do it?
Edit the main fink script, e.g.
$ pico `which fink`

Find these two lines:

# are we root?
if ($> != 0) {

Edit the second line like this:

# are we root?
if (0) {

That's it! Fink will now run non-root, but should also work exactly the 
same when running root. You might want to create a special user just for 
building.

5. Can I set up my fink directory so I can also install non-root?
Probably, but packages that do stuff such as edit the NetInfo database 
will have to be installed as root.

6. How do I rebuild a package without reinstalling it?
Do 'fink rebuild' non-root and ignore the error when it tries to 
reinstall it.

7. How might this situation be improved in the future?
If fink can run under fakeroot, it should be able to do everything it 
needs to do without being able to do anything it shouldn't do (more or 
less). Unfortunately, fakeroot has not yet been ported to Darwin. I 
tried a while ago, but ran up against differing semaphore models. But if 
you know about that sort of thing, you should have a go...

-- 
Ashley Yakeley, Seattle WA


___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


- End Forwarded Message -

-- 
Ashley Yakeley, Seattle WA



---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Re: Safety

[Ashley Yakeley]

In article <[EMAIL PROTECTED]>,
 Martin Costabel <[EMAIL PROTECTED]> wrote:

> > 1. Have fink build as non-root. However, to do this properly I think 
> > this requires the use of fakeroot. If anyone wants to port fakeroot, 
> > they'd be doing the fink community an enormous favour.
> 
> Probably, but this wouldn't have helped here. The catastrophe happens 
> when the package is installed by dpkg, not when it is built.

Right. But if I were wondering about fink accidentally causing serious 
system damage, I would have guessed the build process. If anyone does 
manage to port fakeroot, fink should certainly use it.

> > 2. After the dpkg is built, fink should check it to make sure that all 
> > the files are within %p (or within other directories somehow explicitly 
> > mentioned in the .info file).
> 
> I would rather hope that in future the kind of error that happened here 
> will somehow get detected by human eyes before it can do much 
> destruction. I would regret it if my oversight were the reason for the 
> introduction of some heavy bureaucracy into fink that would be useful 
> only in extremely exceptional cases.

I really see this as a simple sanity check on the dpkg. There are very 
few packages that install outside of %p and no other package info files 
need be affected.

-- 
Ashley Yakeley, Seattle WA



---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Re: add in fink's docs, faq or help section

[David R. Morrison]

Thanks for the suggestion.  However, using any of the --force flags from
dpkg should really be a last resort, not something that people do very
often.  The problem is, when you do this you can leave your Fink installation
in an inconsistent state, and it may later be impossible to fix it again.

So I'm not actually in favor of adding this to the docs.  But I'm forwarding
your message (and my response) to the fink-devel mailing list in case
there are other opinions.

  -- Dave

Aaron Gerber <[EMAIL PROTECTED]> wrote:

> I'm not exactly sure where this email should go, but
> hopefully you're either the right one or you'll know who to
> forward it to.
>
> I've looked through the docs, FAQ and help sections on
> fink.sf.net and can't find this stuff on there.  Maybe it is
> and I'm just not finding it, but if it isn't on there some
> where, I think it would be very helpful to people like

[snip]

> When you try to update packages and they compile, but the
> .deb files won't install because it says that it conflicts
> with packages that are install and you have to:
> sudo dpkg --remove --force-depends 
> and then try to reinstall.
>
> Not a big deal, but I think a lot of people might find this
> info helpful if it isn't already on the website.

Thanks!

Aaron-



---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Safety

[Corrin Lakeland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, 01 Feb 2003 23:02, Ashley Yakeley wrote:

> 1. Have fink build as non-root. However, to do this properly I think
> this requires the use of fakeroot. If anyone wants to port fakeroot,
> they'd be doing the fink community an enormous favour.

You're right, I would love fakeroot, but the porting is nontrivial.  At 
least when I looked at it (6 months ag), it depended on some very new 
features of (was it glibc? or similar) and the porting effort for that 
had only just started.


However, running fink without root really isn't that hard.  There is a 
patch on sourceforge that does it (I think the patch is somewhat out of 
date, mail me if you'd like a newer one). I personally think the 
standard way of running fink should be to add a new user to the system 
(called fink) and install all software as them, so as to not risk root 
if setuid software is compromised.

Almost all unix software copes with being compiled and installed by 
non-root, even when the software that requires root to run. The number 
one problem I have is with fink maintainers, who happily put chowns in 
the .info file, forgetting it prevents installation by non root.


> The point is not to be secure against malicious packages, but to be
> safer against accidental errors.

Agreed, being secure against malicious packages is near impossible, so 
shouldn't really be attempted.

Corrin

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+PDhBi5A0ZsG8x8cRAgeRAJ9FROUiyfcdl9YRvW05RwX43xJmjACggOgc
B6pA/K4QRJeVUyF2p8pfT5s=
=4pTd
-END PGP SIGNATURE-


---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] new teTeX

[David R. Morrison]

A major new release of teTeX is imminent.  If anyone would like to help
me test it, I've got packages called "tetex-texmf-beta" and "tetex-beta"
for the current release candidate, in the experimental/dmrrsn CVS
module.

  -- Dave


---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] XFree86 4.3.0 close

[Jeff Whitaker]

On Sat, 1 Feb 2003, Max Horn wrote:

> At 5:52 Uhr -0700 01.02.2003, jeff whitaker wrote:
> >Ben:  Thanks for the update.  I'm somewhat at a loss of how to proceed
> >with a 4.3.0 package.  Since it contains thread support, it should replace
> >both xfree86-base and xfree86-base-threaded.  At the same time, I'd like
> >to merge the -base and -rootless variants.  So, the new package should
> >replace xfree86-base, -base-threaded, -rootless and -rootless-threaded.
> >Unfortunately, with all the intertwined dependencies I think this is
> >impossible.  So, I think we may have to resort to telling people to use
> >the dreaded "dpkg -r --force-depends" in order to make this transition.
> >Have you found a way around this with your experimental package?
>
> You analysis is right, this is impossible. I tried it (and you, too)
> some time after chrisp left, and already then (with only two
> packages) it was impossible, without --force-depends.
>
>
>
> Cheers,
>
> Max
>

Max et al:  Can you think of a way to automate the "dpkg -r
--force-depends" when upgrading to xfree86-4.3.0?  Is there any way for
fink to pass these arguments to dpkg?  Perhaps it could be done in the
preinst script?

-Jeff

 --
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC  R/CDC1FAX   : (303)497-6449
325 BroadwayWeb   : http://www.cdc.noaa.gov/~jsw
Boulder, CO, USA 80305-3328 Office: Skaggs Research Cntr 1D-124


---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] docbook-bundle-4.1.2-2 fails to install!

[David R. Morrison]

It's not Fink's exectuable, it's Apple's.  You'll need to copy /usr/bin/head
from some other OS X machine (running the same version as you).

  -- Dave


Date: Sat, 01 Feb 2003 09:38:02 -0500
Subject: Re: [Fink-devel] docbook-bundle-4.1.2-2 fails to install!
From: Mark Knipfer <[EMAIL PROTECTED]>
To: "David R. Morrison" <[EMAIL PROTECTED]>
CC: Mark Knipfer <[EMAIL PROTECTED]>


On 2/1/03 9:32 AM, "David R. Morrison" <[EMAIL PROTECTED]> wrote:

> http://fink.sourceforge.net/faq/comp-general.php#head

Excerpt from web page:

This happens when you install the Perl libwww library on an HFS+ system
volume. It tries to create a new command /usr/bin/HEAD , which overwrites
the existing head command because the file system is case-insensitive. head
is a standard command used in many shell scripts and Makefiles. You need to
get the original head executable back if you want to use Fink.


Question:

How do I get the Fink's original head executable back?

Thank you for your prompt response.



---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] docbook-bundle-4.1.2-2 fails to install!

[Peter O'Gorman]

Your head is broken, I assume you used CPAN or something to  
update/install a perl module and you got a /usr/bin/HEAD which  
overwrote your original /usr/bin/head.

Get your old head back and all will be fine.

Peter

On Saturday, February 1, 2003, at 11:18  PM, Mark Knipfer wrote:



In Mac OS X 10.2.3, when I select to install the docbook-bundle, or  
when
other applications try to install where docbook tries to install, the
docbook always fails to install with the same result, see below.

How do I correct this problem?  It is preventing me from installing  
other
programs through Fink 0.5.1/FinkCommander 0.4.3 (v0.4.3).
head -n 28
/sw/src/root-docbook-dtd-4.1.2-3/sw/share/xml/dtd/docbookx/4.1.2/ 
docbookx.dt
d > /sw/src/root-docbook-dtd-4.1.2-3/sw/share/doc/docbook-dtd/COPYRIGHT
Unknown option: n
Usage: head [-options] ...



---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] docbook-bundle-4.1.2-2 fails to install!

[David R. Morrison]

http://fink.sourceforge.net/faq/comp-general.php#head



---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] docbook-bundle-4.1.2-2 fails to install!

[Mark Knipfer]

--
Package manager version: 0.11.1
Distribution version: 0.5.1
Mac OS X
version: 10.2.3
December 2002 Developer Tools
gcc version: 3.1
make version:
3.79
Feedback Courtesy of FinkCommander


In Mac OS X 10.2.3, when I select to install the docbook-bundle, or when
other applications try to install where docbook tries to install, the
docbook always fails to install with the same result, see below.

How do I correct this problem?  It is preventing me from installing other
programs through Fink 0.5.1/FinkCommander 0.4.3 (v0.4.3).

Here is what I see in the Terminal window:

% /sw/bin/fink install docbook-bundle
sudo /sw/bin/fink  install docbook-bundle
Password:
Reading package info...
Updating package index... done.
Information about 924 packages read in 4 seconds.

The following package will be installed or updated:
 docbook-bundle
The following additional package will be installed:
 docbook-dtd
Do you want to continue? [Y/n]
rm -rf docbook-dtd-4.1.2-3
mkdir -p /sw/src/docbook-dtd-4.1.2-3
unzip -o /sw/src/docbk10.zip
Archive:  /sw/src/docbk10.zip
  inflating: docbook.dtd
mkdir -p /sw/src/docbook-dtd-4.1.2-3/docbk11
unzip -o /sw/src/docbk11.zip
Archive:  /sw/src/docbk11.zip
  inflating: docbook.dtd
mkdir -p /sw/src/docbook-dtd-4.1.2-3/docbk12
unzip -o /sw/src/docbk12.zip
Archive:  /sw/src/docbk12.zip
  inflating: ch03.sgm
  inflating: docbook1.0.dtd
  inflating: docbook1.2.doc.sgml
  inflating: docbook1.2.dtd
  inflating: README
  inflating: sgml.declaration
  inflating: xlsc.sgm
mkdir -p /sw/src/docbook-dtd-4.1.2-3/docbk121
unzip -o /sw/src/docbk121.zip
Archive:  /sw/src/docbk121.zip
  inflating: docbook1.2.1.doc.sgml
  inflating: docbook1.2.1.dtd
  inflating: ORAents.v3m
  inflating: README
  inflating: sgml.declaration
  inflating: xlsc.sgm
mkdir -p /sw/src/docbook-dtd-4.1.2-3/docbk21
unzip -o /sw/src/docbk21.zip
Archive:  /sw/src/docbk21.zip
 extracting: almfullguide.sgm.Z
  inflating: alph.guide.sgm
  inflating: docbook.2.1.dtd
  inflating: sgml.declaration
mkdir -p /sw/src/docbook-dtd-4.1.2-3/docbk221
unzip -o /sw/src/docbk221.zip
Archive:  /sw/src/docbk221.zip
  inflating: docbook.2.2.1.dtd
  inflating: docbook.dcl
  inflating: iso-amsa.gml
  inflating: iso-amsb.gml
  inflating: iso-amsc.gml
  inflating: iso-amsn.gml
  inflating: iso-amso.gml
  inflating: iso-amsr.gml
  inflating: iso-box.gml
  inflating: iso-cyr1.gml
  inflating: iso-cyr2.gml
  inflating: iso-dia.gml
  inflating: iso-grk1.gml
  inflating: iso-grk2.gml
  inflating: iso-grk3.gml
  inflating: iso-grk4.gml
  inflating: iso-lat1.gml
  inflating: iso-lat2.gml
  inflating: iso-num.gml
  inflating: iso-pub.gml
  inflating: iso-tech.gml
  inflating: isodia.ent
  inflating: isomfrk.ent
  inflating: isomopf.ent
  inflating: isomscr.ent
  inflating: msg.exm.sgm
  inflating: README
mkdir -p /sw/src/docbook-dtd-4.1.2-3/docbk23
unzip -o /sw/src/docbk23.zip
Archive:  /sw/src/docbk23.zip
  inflating: calstbl.mod
  inflating: dbgenent.mod
  inflating: dbhier.mod
  inflating: dbpool.mod
  inflating: docbook.cat
  inflating: docbook.dcl
  inflating: docbook.dtd
  inflating: iso-amsa.gml
  inflating: iso-amsb.gml
  inflating: iso-amsc.gml
  inflating: iso-amsn.gml
  inflating: iso-amso.gml
  inflating: iso-amsr.gml
  inflating: iso-box.gml
  inflating: iso-cyr1.gml
  inflating: iso-cyr2.gml
  inflating: iso-dia.gml
  inflating: iso-grk1.gml
  inflating: iso-grk2.gml
  inflating: iso-grk3.gml
  inflating: iso-grk4.gml
  inflating: iso-lat1.gml
  inflating: iso-lat2.gml
  inflating: iso-num.gml
  inflating: iso-pub.gml
  inflating: iso-tech.gml
  inflating: isodia.ent
  inflating: isomfrk.ent
  inflating: isomopf.ent
  inflating: isomscr.ent
  inflating: knownbugs23.html
  inflating: README
mkdir -p /sw/src/docbook-dtd-4.1.2-3/docbk24
unzip -o /sw/src/docbk24.zip
Archive:  /sw/src/docbk24.zip
  inflating: 24CHANGE.TXT
  inflating: ANNOUNCE.TXT
  inflating: CALSTBL.MOD
  inflating: DBGENENT.MOD
  inflating: DBHIER.MOD
  inflating: DBPOOL.MOD
  inflating: DOCBOOK.CAT
  inflating: DOCBOOK.DTD
mkdir -p /sw/src/docbook-dtd-4.1.2-3/docbk241
unzip -o /sw/src/docbk241.zip
Archive:  /sw/src/docbk241.zip
  inflating: 241chg.txt
  inflating: announce.txt
  inflating: calstbl.mod
  inflating: dbgenent.mod
  inflating: dbhier.mod
  inflating: dbpool.mod
  inflating: docbook.cat
  inflating: docbook.dcl
  inflating: docbook.dtd
  inflating: iso-amsa.gml
  inflating: iso-amsb.gml
  inflating: iso-amsc.gml
  inflating: iso-amsn.gml
  inflating: iso-amso.gml
  inflating: iso-amsr.gml
  inflating: iso-box.gml
  inflating: iso-cyr1.gml
  inflating: iso-cyr2.gml
  inflating: iso-dia.gml
  inflating: iso-grk1.gml
  inflating: iso-grk2.gml
  inflating: iso-grk3.gml
  inflating: iso-grk4.gml
  inflating: iso-lat1.gml
  inflating: iso-lat2.gml
  inflating: iso-num.gml
  inflating: iso-pub.gml
  inflating: iso-tech.gml
mkdir -p /sw/src/docbook-dtd-4.1.2-3/docbk30
unzip -o /sw/src/docbk30.zip
Archive:  /sw/src/docbk30.zip
  inflating: 30chg.txt
  inflating: 40issues.txt
  inflating

[Fink-devel] Broken symlinks inside dists/ tree makes index crazy

[Xavier HUMBERT]

I had in my dists/test tree a symlink to the source dir for a package
i'm building. It causes fink index to behave completely crazy !

I think it should be mentioned in the Packaging Doc : Never, Never
make symlinks pointing outside fink's tree. It is BAD

The "Good Practice' is

/sw/fink/dists/test/main/finkinfo/category/mypackage/mypackage-1.0-1.info
 mypackage-1.0-1.patch

and *elsewhere* :

Devel/mypackage/mypackage-1.0.tar.gz
mypackage-1.0/
mypackage-1.0-1.info -> /sw/fink/dists/[...]/mypackage-1.0-1.info
mypackage-1.0-1.patch -> /sw/fink/dists/[...]/mypackage-1.0-1.patch

So you can do, for example
$ diff -Naur mypackage-1.0/Makefile.orig mypackage-1.0/Makefile > mypackage-1.0-1.patch

Hope my error will help :-)

-- 
Xavier
http://www.freetibet.org
http://www.tibet.fr/


---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] XFree86 4.3.0 close

[Max Horn]

At 5:52 Uhr -0700 01.02.2003, jeff whitaker wrote:

Ben:  Thanks for the update.  I'm somewhat at a loss of how to proceed
with a 4.3.0 package.  Since it contains thread support, it should replace
both xfree86-base and xfree86-base-threaded.  At the same time, I'd like
to merge the -base and -rootless variants.  So, the new package should
replace xfree86-base, -base-threaded, -rootless and -rootless-threaded.
Unfortunately, with all the intertwined dependencies I think this is
impossible.  So, I think we may have to resort to telling people to use
the dreaded "dpkg -r --force-depends" in order to make this transition.
Have you found a way around this with your experimental package?


You analysis is right, this is impossible. I tried it (and you, too) 
some time after chrisp left, and already then (with only two 
packages) it was impossible, without --force-depends.



Cheers,

Max


---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] XFree86 4.3.0 close

[jeff whitaker]

Ben:  Thanks for the update.  I'm somewhat at a loss of how to proceed
with a 4.3.0 package.  Since it contains thread support, it should replace
both xfree86-base and xfree86-base-threaded.  At the same time, I'd like
to merge the -base and -rootless variants.  So, the new package should
replace xfree86-base, -base-threaded, -rootless and -rootless-threaded.
Unfortunately, with all the intertwined dependencies I think this is
impossible.  So, I think we may have to resort to telling people to use
the dreaded "dpkg -r --force-depends" in order to make this transition.
Have you found a way around this with your experimental package?

-Jeff

 On Fri, 31 Jan 2003, Benjamin Reed wrote:

> On Friday, January 31, 2003, at 06:46 PM, Torrey Lyons wrote:
>
> > The code freeze for XFree86 4.3.0 will be any day now. I believe the
> > Mac OS X/Darwin part of the code base is pretty much in final form.
> > Benjamin put together a package in fink unstable which builds
> > something very close to the top of the tree. I would encourage as many
> > people as possible to give it a try. The libraries and clients from
> > this version will be used for Apple's final release of X11 although
> > the X server will not be synced up until after 4.3.0 is out. Please
> > let me know promptly if you find any bugs.
> >
> > There has been only one bug fix since Benjamin's package was put
> > together: In 16-bit color pixmaps could sometimes appear shifted by 1
> > pixel from what was intended.
>
> Actually I updated it to a new snapshot as of this morning, so if you
> get it now, you get one that should include that fix (I watch the X
> commits list and saw the bugfixes).
>
> Jeffrey Whitaker is actually the maintainer of XFree86 in Fink, but I
> just wanted to reiterate that the packages in experimental are for the
> most part for my own edification, and because I was doing some testing
> for Torrey.
>
> Jeff, I don't know what your plans are for release, but if you want
> them, feel free to take over the packages in my exp tree.  I'm pretty
> certain they would need looking at, I didn't double-check that the
> shlibs stuff is right and that type of thing, so these aren't
> release-ready in the fink sense, although they're perfectly good for
> helping Torrey test.
>
> As of the last snapshots, things have worked pretty good as far as
> backwards-compatibility with software built against xfree86 4.2, but
> keep in mind that if you plan on testing this, and you build something
> against it, it won't work if you want to go back to 4.2.1.1 (including
> Apple's X11).  =)
>

-- 
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC  R/CDC1FAX   : (303)497-6449
325 BroadwayWeb   : http://www.cdc.noaa.gov/~jsw
Boulder, CO, USA 80305-3328 Office: Skaggs Research Cntr 1D-124


---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Safety

[Martin Costabel]

Ashley Yakeley wrote:

I wrote:



When I installed lcms 1.09-1, it overwrote my /usr/bin directory with a 
file, making my system non-bootable. Note my fink dir is 
"/usr/local/finksw".

I am, of course, very sorry about this bug. Now that I saw it, I don't 
understand how I couldn't have noticed it before. But then nobody else 
did in the past 6 months. It slipped through all controls. The package 
has already been in 0.4.1 stable in the same form.

A short explanation of the bug:

lcms has very simple makefiles, no configure etc. During make install it 
does the following

-cp icctrans $(BINDIR)

where BINDIR was defined as
BASEDIR = $(DESTDIR)/usr
BINDIR  = $(BASEDIR)/bin

In the other Makefiles, I had changed

BASEDIR = $(DESTDIR)/usr
to
BASEDIR = $(DESTDIR)/$(PREFIX)

which then does the right thing, but I forgot to do this patch in one 
subdirectory (in previous versions it hadn't tried to install icctrans).

The resulting command

cp icctrans %d/usr/bin

gives an (ignored) error message when fink's %p is not inside /usr, 
because then %d/usr/ does not exist. icctrans is then silently 
forgotten. If, however, %p is below /usr/, %d/usr/ will exist, but not 
%/usr/bin/, so that the file icctrans is then copied to the *file* 
%d/usr/bin.

And dpkg apparently clobbers everything in its way, so it replaces 
/usr/bin/ by the file /usr/bin.

I wouldn't have thought that dpkg is so merciless. This is as bad as 
Apple's Installer.app.



I've been thinking about how to prevent this sort of thing happening in 
the future. Two things occur to me:

1. Have fink build as non-root. However, to do this properly I think 
this requires the use of fakeroot. If anyone wants to port fakeroot, 
they'd be doing the fink community an enormous favour.

Probably, but this wouldn't have helped here. The catastrophe happens 
when the package is installed by dpkg, not when it is built.

2. After the dpkg is built, fink should check it to make sure that all 
the files are within %p (or within other directories somehow explicitly 
mentioned in the .info file).

I would rather hope that in future the kind of error that happened here 
will somehow get detected by human eyes before it can do much 
destruction. I would regret it if my oversight were the reason for the 
introduction of some heavy bureaucracy into fink that would be useful 
only in extremely exceptional cases.

The point is not to be secure against malicious packages, but to be 
safer against accidental errors.

There is probably some Murphy law saying that bugs are always more 
inventive than the measures trying to prevent them :-(

--
Martin






---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] lcms 1.09-1 install destroys /usr/bin directory

[Martin Costabel]

Ashley Yakeley wrote:

When I installed lcms 1.09-1, it overwrote my /usr/bin directory with a 
file, making my system non-bootable. Note my fink dir is 
"/usr/local/finksw".

The bug is now fixed in version 1.09-2. It is a bug that is dangerous 
only when fink is installed inside /usr/. So there is no danger for 
those who have fink in /sw/.

--
Martin







---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Safety

[Ashley Yakeley]

I wrote:

> When I installed lcms 1.09-1, it overwrote my /usr/bin directory with a 
> file, making my system non-bootable. Note my fink dir is 
> "/usr/local/finksw".
...
>

I've been thinking about how to prevent this sort of thing happening in 
the future. Two things occur to me:

1. Have fink build as non-root. However, to do this properly I think 
this requires the use of fakeroot. If anyone wants to port fakeroot, 
they'd be doing the fink community an enormous favour.

2. After the dpkg is built, fink should check it to make sure that all 
the files are within %p (or within other directories somehow explicitly 
mentioned in the .info file).

The point is not to be secure against malicious packages, but to be 
safer against accidental errors.

-- 
Ashley Yakeley, Seattle WA



---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel