Re: /opt/local/macports/software

[Ryan Schmidt]

On Jan 21, 2015, at 4:24 AM, René J.V. Bertin wrote:

> On Tuesday January 20 2015 19:25:11 Ryan Schmidt wrote:
> 
>>> Why in fact deactivate and then activate anew? Isn't an untar of the 
>>> appropriate tarball enough?
> 
>> It's never occurred to me before. I don't think the type of people who 
>> typically get into this situation are the ones who would want to do that.
> 
> :) I guess one could argue that `port activate -f` (or is that -f 
> activate...) could/should do that?

I don't know whether "port -f activate" would do anything, or do anything 
useful, on a port that is already active.


>> I wrote a script to do that in 2009. The problem is that a normal proper 
>> MacPorts installation actually contains many many files that are not 
>> registered to a port. That includes all files provided by MacPorts base, 
>> cache files, log files, config files...
> 
> Those are all in the portdbpath, no? 

I'm speaking of files like:

>> all files provided by MacPorts base,

e.g. /opt/local/bin/port, /opt/local/bin/portindex, 
/opt/local/etc/macports/macports.conf.default, etc.

Not to mention everything in /opt/local/var/macports/

>> cache files,

e.g. everything in /opt/local/var/cache/fontconfig/, etc.

>> log files,

e.g. /opt/local/var/log/mongodb/mongodb.log, 
/opt/local/var/log/nginx/access.log, etc.

>> config files...

e.g. /opt/local/apache2/conf/httpd.conf, /opt/local/etc/macports/macports.conf, 
/opt/local/etc/php55/php.ini, etc.


___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Brandon Allbery]

On Tue, Jan 20, 2015 at 7:24 PM, René J.V.  wrote:

> Something related came up in another discussion I had today, which raised
> the question how hard it would be to write a walker that 1) identifies
> stray and/or trespassing files


Config files are not part of a port/package, because if they were then any
(often necessary) customization would be overwritten on port upgrade.
(Binary package managers often handle this by flagging them for special
handling... and still get it wrong often enough that I usually check
manually after upgrades.) Likewise things like databases (whether things
like mysql/mariadb/postgresql or support databases like scrollkeeper), the
DocumentRoot of web servers, etc. In short, this isn't even remotely
trivial.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Ryan Schmidt]

On Jan 20, 2015, at 6:24 PM, René J.V. Bertin wrote:

> On Tuesday January 20 2015 17:42:27 Ryan Schmidt wrote:
> 
> Why in fact deactivate and then activate anew? Isn't an untar of the 
> appropriate tarball enough?

That's true, but the MacPorts commant to untar the tarball is "activate", and 
MacPorts will not allow you to "activate" a port that is already active, so you 
deactivate it first. If you prefer to figure out the command to untar the 
tarball and run that manually instead of using port commands, you can do that. 
It's never occurred to me before. I don't think the type of people who 
typically get into this situation are the ones who would want to do that.


>> Granted, in the case that the user has installed such a third-party 
>> installer, I actually recommend they completely uninstall MacPorts and all 
>> ports, then reinstall MacPorts and the desired ports, to be sure that no 
>> additional unwanted files are in /opt/local.
> 
> Something related came up in another discussion I had today, which raised the 
> question how hard it would be to write a walker that 1) identifies stray 
> and/or trespassing files

I wrote a script to do that in 2009. The problem is that a normal proper 
MacPorts installation actually contains many many files that are not registered 
to a port. That includes all files provided by MacPorts base, cache files, log 
files, config files...

> and 2) compares files with the copy in the software archive.

I haven't considered writing such a script. Sounds easy enough to do, but it 
would only be useful in situations where the user has corrupted their 
MacPorts-installed files, e.g. by running a badly-made third-party installer. I 
would rather focus effort on avoiding that situation ever happening in the 
first place. For example, whenever someone reports that this situation has 
occurred to them, we should attempt to discover which third-party installer 
they have used, then work with the developer of that third-party installer to 
fix it so that it no longer overwrites our files, and improving our 
documentation to explain to third-party developers how to create installers 
that avoid this problem.



___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Bradley Giesbrecht]

On Jan 20, 2015, at 3:42 PM, Ryan Schmidt  wrote:

> On Jan 20, 2015, at 2:12 AM, Akim Demaille wrote:
>> 
>> Le 19 janv. 2015 à 11:07, Ryan Schmidt a écrit :
>>> 
>>> On Jan 19, 2015, at 3:59 AM, Akim Demaille wrote:
>>>> 
>>>> You're talking implementation details, I'm talking feature.  And the
>>>> implementation is straightforward: rm -f 
>>>> /opt/local/macports/software/
>>>> when  was activated.
>>> 
>>> It's quite a lot more than just that. You're asking for a way for the user 
>>> to opt in to auto-removal of archives and opt out of the ability to use the 
>>> deactivate feature. MacPorts currently relies on the deactivate feature 
>>> during uninstallation, so there would be changes required there as well.
>> 
>> I have a question: what exactly is in the archive?
> 
> You can decompress it yourself to take a look: it contains all the files 
> installed by the port, and also a copy of the Portfile itself and some other 
> metadata.
> 
>> Why is that that
>> deactivate does not archive what was installed on the disk?  I mean,
>> if the archives is exactly what is deployed, then it's pure duplication,
>> including in an activate/deactivate scenario: one copy should be enough,
>> be it deployed, or compressed, no?  Maybe that would be less invasive,
>> I don't know.
> 
> Because nobody (at least not me) thought to program it that way.
> 
> There is also a problem which occurs more often than it should, which is 
> this: a user installs MacPorts in its default prefix, and installs some 
> ports, and then installs a third-party software installer, which was itself 
> built with MacPorts in its default prefix. Developers should not create 
> installers of MacPorts-provided software with MacPorts in its default prefix 
> (they should custom-configure MacPorts to a prefix unique to their software), 
> but they do. Users should not install such misconfigured installers, but they 
> do. And the consequence is that the files of some the user's installed ports 
> are now overwritten with older versions, or versions built for the wrong 
> architecture. Currently, a user can work around that by deactivating the port 
> (i.e. deleting all the files the port installed), then reactivating the port 
> (i.e. decompressing the archive which contains the correct versions of the 
> files).

This is a wonderful sanity check. Unsure? Deactivate/activate, certainty 
restored.


Regards,
Bradley Giesbrecht (pixilla)



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[René J . V . Bertin]

On Tuesday January 20 2015 17:42:27 Ryan Schmidt wrote:

Why in fact deactivate and then activate anew? Isn't an untar of the 
appropriate tarball enough?

> Granted, in the case that the user has installed such a third-party 
> installer, I actually recommend they completely uninstall MacPorts and all 
> ports, then reinstall MacPorts and the desired ports, to be sure that no 
> additional unwanted files are in /opt/local.

Something related came up in another discussion I had today, which raised the 
question how hard it would be to write a walker that 1) identifies stray and/or 
trespassing files and 2) compares files with the copy in the software archive. 
Point 2) could actually be done by simply reactivating each port if there's no 
need to identify modified files. Point 1) is probably harder and certainly more 
resource intensive than it sounds, but it should beat a complete reinstall by 
more than a few lengths ...

R.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Ryan Schmidt]

On Jan 20, 2015, at 2:12 AM, Akim Demaille wrote:
> 
> Le 19 janv. 2015 à 11:07, Ryan Schmidt a écrit :
>> 
>> On Jan 19, 2015, at 3:59 AM, Akim Demaille wrote:
>>> 
>>> You're talking implementation details, I'm talking feature.  And the
>>> implementation is straightforward: rm -f /opt/local/macports/software/
>>> when  was activated.
>> 
>> It's quite a lot more than just that. You're asking for a way for the user 
>> to opt in to auto-removal of archives and opt out of the ability to use the 
>> deactivate feature. MacPorts currently relies on the deactivate feature 
>> during uninstallation, so there would be changes required there as well.
> 
> I have a question: what exactly is in the archive?

You can decompress it yourself to take a look: it contains all the files 
installed by the port, and also a copy of the Portfile itself and some other 
metadata.

> Why is that that
> deactivate does not archive what was installed on the disk?  I mean,
> if the archives is exactly what is deployed, then it's pure duplication,
> including in an activate/deactivate scenario: one copy should be enough,
> be it deployed, or compressed, no?  Maybe that would be less invasive,
> I don't know.

Because nobody (at least not me) thought to program it that way.

There is also a problem which occurs more often than it should, which is this: 
a user installs MacPorts in its default prefix, and installs some ports, and 
then installs a third-party software installer, which was itself built with 
MacPorts in its default prefix. Developers should not create installers of 
MacPorts-provided software with MacPorts in its default prefix (they should 
custom-configure MacPorts to a prefix unique to their software), but they do. 
Users should not install such misconfigured installers, but they do. And the 
consequence is that the files of some the user's installed ports are now 
overwritten with older versions, or versions built for the wrong architecture. 
Currently, a user can work around that by deactivating the port (i.e. deleting 
all the files the port installed), then reactivating the port (i.e. 
decompressing the archive which contains the correct versions of the files). If 
the archive isn't there, and is recreated by deactivating, then deactivating 
and reactivating does nothing useful, and additionally takes a lot more time 
than it does now.

Granted, in the case that the user has installed such a third-party installer, 
I actually recommend they completely uninstall MacPorts and all ports, then 
reinstall MacPorts and the desired ports, to be sure that no additional 
unwanted files are in /opt/local.



___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Akim Demaille]

> Le 20 janv. 2015 à 13:20, René J.V. Bertin  a écrit :
> 
>> If you have a system with
>> say a SSD 128 GB drive, I do not think it is then unreasonable for that
>> user to ask why they have to lug around GBs of archives which, unless
>> you regular use the activate/deactivate feature (and I still suspect the
>> majority of users do not) is of rather limited benefit.
> 
> It has already been pointed out that you can set up MP to put all of that on 
> external storage, even a JetDrive or MiniDrive. The whole tree in which the 
> software directory resides (var/macports) is used only be the port command, 
> so as long as you don't use that you don't need to have var/macports online.

Right.  But that means that you have to have that drive at hand.
The machine I'm using belongs to my company, and I'm traveling.
Sometimes I'm far from my place, yet I want to upgrade.  And
I don't want to have to carry an additional external drive.

So I agree it mitigates the problem, but it certainly does not
address it.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Chris Jones]

On 20/01/15 02:37, Joshua Root wrote:

Daniel J. Luke wrote:

On Jan 19, 2015, at 6:34 AM, René J.V. Bertin  wrote:
What could be an option:
- use xz instead of bzip2 to compact things a bit more


this would probably be a small change (I think there's support for gzip and zip 
already) - but changing your local archive type means you won't get binary 
archives.


This was true in the past, but no longer. Setting portarchivetype only
affects the type of archives that are generated when building locally.
Each archive site now has an associated archive type, which happens to
be tbz2 for packages.macports.org and its mirrors.

We do support building txz archives already, and they can happily
coexist with downloaded tbz2 ones. The catch is that you have to have
the xz port installed to install or activate any txz archives. So the
default is not going to change unless/until Apple starts shipping xz
with OS X.


Or... MP starts shipping xz as a requirement, such as is done with TCL. 
If using xv saves more than it takes up (almost certainly the case) it 
is something to consider.


Chris



- Josh
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users



___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Chris Jones]

Hi,

On 20/01/15 02:49, Craig Treleaven wrote:

At 8:20 PM + 1/19/15, Chris Jones wrote:

 > On 19 Jan 2015, at 7:13 pm, Craig Treleaven
 wrote:
 > At 3:11 PM + 1/19/15, Chris Jones wrote:

 ...


 Does anyone else find it bizarre that, in 2015, we've got such an
active thread about saving a few gigs of space?


Nope. Saving disk space when not required is always a good idea.


If I buy a sub-compact car, I can hardly complain that my skiis won't
fit inside.I truly understand cost constraints and tradeoffs. However,
if a compressed archive of MacPorts-installed packages is the tipping
point for your system...I'd say you're running far too close to the edge.


Its not a matter of being close to the edge. If you have a system with 
say a SSD 128 GB drive, I do not think it is then unreasonable for that 
user to ask why they have to lug around GBs of archives which, unless 
you regular use the activate/deactivate feature (and I still suspect the 
majority of users do not) is of rather limited benefit.


Don't get me wrong, I also do understand why MP does this. I am just say 
IMO its a reasonable question to ask.



 > If one has a too-small SSD, it seems more-than-a-little strange to
complain that building/installing a bunch of software packages
consumes it.  Get a bigger drive.  Or smaller expectations.

And how pray does one do that in a Mac Book with non-upgradable Solid
state storage...


Upgrade:

http://eshop.macsales.com/shop/SSD/OWC


Great, for those in the US .. Plus I don't think upgrading is available 
for all Macs with built in SSDs (might be wrong there, but I think so).




Or the time-honoured fashion in the Apple world...trade up.


I am not sure the 'spend you way out' is the right answer here.

Chris
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Vincent Habchi]

> On 20 Jan 2015, at 03:49, Craig Treleaven  wrote:
> Upgrade:
> http://eshop.macsales.com/shop/SSD/OWC

I, for example, have a MacBook Air 6,2 with the PCIe SSD. No upgrade available. 
:(

Vincent


___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Brandon Allbery]

On Tue, Jan 20, 2015 at 3:12 AM, Akim Demaille  wrote:

> Also, do people really use deactivate/activate offline?


Yes, effectively; my local Internet connection is kinda crap at times. Also
I use it with ports that can't be packaged for licensing reasons, or
because of non-default variants (indeed, sometimes to quick-switch between
variants). (We can't package non-default variants sanely because it would
lead to a combinatorial explosion of dependencies with different variants.)

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Mojca Miklavec]

On Tue, Jan 20, 2015 at 9:12 AM, Akim Demaille  wrote:
>
> Also, do people really use deactivate/activate offline?

Yes. I do.

(While I'm usually on a fast internet connection, sometimes the
connection is just as limited and expensive (3G) as hard disk
replacements for the first laptops with tiny SSDs. Or non-existent.)

Mojca
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Akim Demaille]

Hi Ryan, Hi all,

> Le 19 janv. 2015 à 11:07, Ryan Schmidt  a écrit :
> 
> On Jan 19, 2015, at 3:59 AM, Akim Demaille wrote:
>> 
>> You're talking implementation details, I'm talking feature.  And the
>> implementation is straightforward: rm -f /opt/local/macports/software/
>> when  was activated.
> 
> It's quite a lot more than just that. You're asking for a way for the user to 
> opt in to auto-removal of archives and opt out of the ability to use the 
> deactivate feature. MacPorts currently relies on the deactivate feature 
> during uninstallation, so there would be changes required there as well.

I have a question: what exactly is in the archive?  Why is that that
deactivate does not archive what was installed on the disk?  I mean,
if the archives is exactly what is deployed, then it's pure duplication,
including in an activate/deactivate scenario: one copy should be enough,
be it deployed, or compressed, no?  Maybe that would be less invasive,
I don't know.

Also, do people really use deactivate/activate offline?
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Jeremy Lavergne]

When MS Office singlehandedly uses up all the drive on those tiny drives, I 
cannot feel sorry that there's no room left for MacPorts--because there's 
already no room left for anything before MacPorts even enters the picture.

On January 19, 2015 9:49:43 PM EST, Craig Treleaven  
wrote:
>At 8:20 PM + 1/19/15, Chris Jones wrote:
>>  > On 19 Jan 2015, at 7:13 pm, Craig Treleaven 
>> wrote:
>>  > At 3:11 PM + 1/19/15, Chris Jones wrote:
  ...
>>>
>>>  Does anyone else find it bizarre that, in 2015, we've got such an 
>>>active thread about saving a few gigs of space?
>>
>>Nope. Saving disk space when not required is always a good idea.
>
>If I buy a sub-compact car, I can hardly complain that my skiis won't 
>fit inside.  I truly understand cost constraints and tradeoffs. 
>However, if a compressed archive of MacPorts-installed packages is 
>the tipping point for your system...I'd say you're running far too 
>close to the edge.
>
>>  > If one has a too-small SSD, it seems more-than-a-little strange 
>>to complain that building/installing a bunch of software packages 
>>consumes it.  Get a bigger drive.  Or smaller expectations.
>>
>>And how pray does one do that in a Mac Book with non-upgradable 
>>Solid state storage...
>
>Upgrade:
>
>http://eshop.macsales.com/shop/SSD/OWC
>
>Or the time-honoured fashion in the Apple world...trade up.
>
>Craig
>___
>macports-users mailing list
>macports-users@lists.macosforge.org
>https://lists.macosforge.org/mailman/listinfo/macports-users

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Craig Treleaven]

At 8:20 PM + 1/19/15, Chris Jones wrote:
 > On 19 Jan 2015, at 7:13 pm, Craig Treleaven 
 wrote:

 > At 3:11 PM + 1/19/15, Chris Jones wrote:

 ...


 Does anyone else find it bizarre that, in 2015, we've got such an 
active thread about saving a few gigs of space?


Nope. Saving disk space when not required is always a good idea.


If I buy a sub-compact car, I can hardly complain that my skiis won't 
fit inside.  I truly understand cost constraints and tradeoffs. 
However, if a compressed archive of MacPorts-installed packages is 
the tipping point for your system...I'd say you're running far too 
close to the edge.


 > If one has a too-small SSD, it seems more-than-a-little strange 
to complain that building/installing a bunch of software packages 
consumes it.  Get a bigger drive.  Or smaller expectations.


And how pray does one do that in a Mac Book with non-upgradable 
Solid state storage...


Upgrade:

http://eshop.macsales.com/shop/SSD/OWC

Or the time-honoured fashion in the Apple world...trade up.

Craig
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

/opt/local/macports/software

[Joshua Root]

Daniel J. Luke wrote:
>> On Jan 19, 2015, at 6:34 AM, René J.V. Bertin  wrote:
>> What could be an option:
>> - use xz instead of bzip2 to compact things a bit more
> 
> this would probably be a small change (I think there's support for gzip and 
> zip already) - but changing your local archive type means you won't get 
> binary archives.

This was true in the past, but no longer. Setting portarchivetype only
affects the type of archives that are generated when building locally.
Each archive site now has an associated archive type, which happens to
be tbz2 for packages.macports.org and its mirrors.

We do support building txz archives already, and they can happily
coexist with downloaded tbz2 ones. The catch is that you have to have
the xz port installed to install or activate any txz archives. So the
default is not going to change unless/until Apple starts shipping xz
with OS X.

- Josh
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Ryan Schmidt]

On Jan 19, 2015, at 7:31 PM, René J.V. Bertin wrote:

> On Monday January 19 2015 19:05:40 Ryan Schmidt wrote:
>> 
>>> IMHO the argument is stupid. If you **need** those gigs then buy them. I 
>>> just bought 1T at $0.0089 / gig !!
>> 
>> Conserving disk space is a valid concern. Many Macs made in the past few 
>> years have an internal SSD and do not have internal space for a hard drive.
> 
> Of course it is. But one doesn't buy such a Mac without knowing its 
> limitations (fashion victims aside, but who's going to pity them? ;)) and the 
> compromises that imposes. A compact Mac with a non-upgradable SSD is 
> undoubtedly great for certain "serious" uses, but not so great for other 
> serious work that requires installing a huge selection of ports...

I didn't say non-upgradable. OWC makes upgrades for the internal SSD of many 
Apple laptops, for example:

http://eshop.macsales.com/shop/SSD/OWC

Yes, I was aware of the compromises when I purchased my MacBook Pro with Retina 
Display 2.5 years ago. Yes, I paid extra for a larger SSD than the standard 
one. Yes, it is nevertheless full now.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Ryan Schmidt]

On Jan 19, 2015, at 7:15 PM, René J.V. Bertin wrote:

> On Monday January 19 2015 17:21:14 Ryan Schmidt wrote:
> 
>> Spotlight would find items in the /opt/local/var/macports/software 
>> directory. So when you were trying to launch an application in 
>> /Applications/MacPorts, it might find the copy in 
>> /opt/local/var/macports/software instead, which might not work.
> 
> That was before macports/software contained tarballs, I presume.

Correct, that's what we're talking about here: the problems with 
/opt/local/var/macports/software containing "images" (directories containing 
the actual files), and why we changed MacPorts to use "archives" (compressed 
tarballs) instead.


>> That would be a possible solution for the Spotlight issues but not for the 
>> Time Machine issues.
> 
> Why not for Time Machine? It can't (or rather, couldn't) make duplicate 
> backups if one of the 2 sources is in an excluded directory, yes?

Which directory would you exclude?

If you exclude /opt/local/var/macports/software, then you cannot restore that 
directory from backups and you'll have a broken MacPorts installation (one 
which cannot re-activate deactivated ports).

If you exclude the "real" installation directory, that means excluding all of 
MacPorts i.e. /opt/local and /Applications/MacPorts.

With "images", not only were all the MacPorts-installed files backed up twice, 
taking twice the disk space, but if you restored such a backup, then the files 
would be duplicated on your real machine too.

The reasons for switching from "images" to "archives" all those years ago were 
sound, we don't need to re-hash this discussion again.


>> I also do not know what would happen if a user who already has ports 
>> installed with bz2 archives suddenly changes the archive format to xz (or, 
>> more generally, makes any change to the archive format). Would MacPorts 
>> still know how to find the existing archive and remove it when a port is 
>> uninstalled or upgraded?
> 
> I suppose there is normally only 1 tarball per installed version or variant, 
> so the search algorithm could omit the compressor extension from the search 
> pattern. 

Yes, solutions could be invented. I'm questioning whether we already have a 
solution coded. If not, that's more code someone would have to write and test.


>>> What parts of ${prefix}/var/macports are used during normal operation, so 
>>> as long as you don't use the port command?
>> 
>> None. That directory is for the port command to use, and nobody else.
> 
> So it could indeed be on a removable/external drive that's mounted only for 
> port maintenance.

It's conceivable, but not tested by me.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[René J . V . Bertin]

On Monday January 19 2015 19:05:40 Ryan Schmidt wrote:
> 
> > IMHO the argument is stupid. If you **need** those gigs then buy them. I 
> > just bought 1T at $0.0089 / gig !!
> 
> Conserving disk space is a valid concern. Many Macs made in the past few 
> years have an internal SSD and do not have internal space for a hard drive.

Of course it is. But one doesn't buy such a Mac without knowing its limitations 
(fashion victims aside, but who's going to pity them? ;)) and the compromises 
that imposes. A compact Mac with a non-upgradable SSD is undoubtedly great for 
certain "serious" uses, but not so great for other serious work that requires 
installing a huge selection of ports...


___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[René J . V . Bertin]

On Monday January 19 2015 17:21:14 Ryan Schmidt wrote:

> Spotlight would find items in the /opt/local/var/macports/software directory. 
> So when you were trying to launch an application in /Applications/MacPorts, 
> it might find the copy in /opt/local/var/macports/software instead, which 
> might not work.

That was before macports/software contained tarballs, I presume.

> That would be a possible solution for the Spotlight issues but not for the 
> Time Machine issues.

Why not for Time Machine? It can't (or rather, couldn't) make duplicate backups 
if one of the 2 sources is in an excluded directory, yes?

> I also do not know what would happen if a user who already has ports 
> installed with bz2 archives suddenly changes the archive format to xz (or, 
> more generally, makes any change to the archive format). Would MacPorts still 
> know how to find the existing archive and remove it when a port is 
> uninstalled or upgraded?

I suppose there is normally only 1 tarball per installed version or variant, so 
the search algorithm could omit the compressor extension from the search 
pattern. 

> > What parts of ${prefix}/var/macports are used during normal operation, so 
> > as long as you don't use the port command?
> 
> None. That directory is for the port command to use, and nobody else.

So it could indeed be on a removable/external drive that's mounted only for 
port maintenance.

R
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[René J . V . Bertin]

On Monday January 19 2015 18:38:52 Ryan Schmidt wrote:

> >> Just to be clear: I do agree with this, and practice it myself. One of the 
> >> reasons MacPorts is not installed on my boot partition.
> >> (heck, I'm old and pedantic enough to care about free space fragmentation 
> >> ...)
> > 
> > Which is great until 10.9+ refuse to load your launchd plists because the 
> > external drive isn't mounted during system boot 
> 
> Yeah, we need to fix that. 

That was already the case with 10.6, and doesn't really bother me.

R
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Ryan Schmidt]

On Jan 19, 2015, at 6:58 PM, James Linder wrote:
> 
> IMHO the argument is stupid. If you **need** those gigs then buy them. I just 
> bought 1T at $0.0089 / gig !!

Conserving disk space is a valid concern. Many Macs made in the past few years 
have an internal SSD and do not have internal space for a hard drive.


___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[James Linder]

> On 20 Jan 2015, at 4:00 am, macports-users-requ...@lists.macosforge.org wrote:
> 
>> Le 19 janv. 2015 ? 10:54, Ryan Schmidt  a ?crit :
>>> So maybe we could reconsider the existence of this feature, or at least,
>>> the fact that its mandatory.
>> 
>> If I remember correctly, the code for the old way with hard links was 
>> removed from MacPorts. There is no way to go back to that method, without 
>> rewriting the code.
> 
> You're talking implementation details, I'm talking feature.  And the
> implementation is straightforward: rm -f /opt/local/macports/software/
> when  was activated.
> 
>>> Well, apt-get and the rest have no such equivalent.  They just deploy
>>> the software, period.  They don't keep a copy at hand, just in case.
>>> And yes, there's no acivate/deactivate (that I know of).
>> 
>> If your installed files have become damaged, for example because a 
>> third-party installer overwrote them, it's very nice to be able to fix it by 
>> simply deactivating and re-activating the port.
> 
> Yes, I'm sure it's nice.  I'm not saying the feature is useless, I'm
> saying I don't want to use it.
> 
>> apt-get is not typically used on OS X, which is the platform where concerns 
>> regarding Spotlight and Time Machine occur. It would be more interesting to 
>> compare against the other OS X package managers, Homebrew or Fink.
> 
> I don't see how the OS is relevant in anyway here.

/var/cache is where apt-get stores everything
IMHO the argument is stupid. If you **need** those gigs then buy them. I just 
bought 1T at $0.0089 / gig !!

James
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Ryan Schmidt]

On Jan 19, 2015, at 6:30 PM, Brandon Allbery wrote:
> On Mon, Jan 19, 2015 at 3:31 PM, René J.V. wrote:
>> Just to be clear: I do agree with this, and practice it myself. One of the 
>> reasons MacPorts is not installed on my boot partition.
>> (heck, I'm old and pedantic enough to care about free space fragmentation 
>> ...)
> 
> Which is great until 10.9+ refuse to load your launchd plists because the 
> external drive isn't mounted during system boot 

Yeah, we need to fix that. 

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Brandon Allbery]

On Mon, Jan 19, 2015 at 3:31 PM, René J.V.  wrote:

> Just to be clear: I do agree with this, and practice it myself. One of the
> reasons MacPorts is not installed on my boot partition.
> (heck, I'm old and pedantic enough to care about free space fragmentation
> ...)


Which is great until 10.9+ refuse to load your launchd plists because the
external drive isn't mounted during system boot

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Eric A. Borisch]

On Mon, Jan 19, 2015 at 5:21 PM, Ryan Schmidt 
wrote:

>
> > - use xz instead of bzip2 to compact things a bit more
>
> Whatever compression format is used needs to be supported without the use
> of any port. OS X does not include support for dealing with xz files, which
> is one reason why bz2 files were chosen instead. Changing this would
> involve bundling a copy of the xz utilities with MacPorts; changing the
> default archive format from bz2 to xz in archive_sites.conf and
> macports.conf; re-building all ports on all buildbot builders with this new
> version of MacPorts; and upgrading all users to this new version of
> MacPorts. I also do not know what would happen if a user who already has
> ports installed with bz2 archives suddenly changes the archive format to xz
> (or, more generally, makes any change to the archive format). Would
> MacPorts still know how to find the existing archive and remove it when a
> port is uninstalled or upgraded?


FWIW; running (xz -9) over the .tbz2 files (well, running them through
bzip2 -d first) showed that using xz could shave 40% off the storage
requirements for the archives.

I have a range of items installed, but by far the largest (and the ones
with some of the largest improvements were clang-3.5 (50% reduction)
llvm-3.5 (49% reduction) and gcc48 and 49 (both ~50% the tbz2 size; only
saved 20% with "xz" (no -9)).

qt4-mac showed only a 15% reduction, so there is certainly a range.
Text-heavy items are likely to do the best (if I recall...)

I don't think adding code to look for .(xz|tbz2) (or even trying
to fetch both) is a crazy idea. This wouldn't require rebuilding all of the
existing packages, either. Yes, it would require adding xz to the list of
"shipped with" items." Thankfully, it only takes about 20s to configure and
build (on my machine) and the resulting files are only about 1M.

Just putting some actual numbers out there for what xz brings to the table.

 - Eric
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Dave Horsfall]

On Mon, 19 Jan 2015, René J.V. Bertin wrote:

> Just to be clear: I do agree with this, and practice it myself. One of 
> the reasons MacPorts is not installed on my boot partition. (heck, I'm 
> old and pedantic enough to care about free space fragmentation ...)

I'm glad to know that I'm not the only pedantic old fart around here.  I 
turn 63 this year, and I'm not getting much younger.

-- 
Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Ryan Schmidt]

On Jan 19, 2015, at 9:49 AM, René J.V. Bertin wrote:

>>> Similarly, is there a way to disable the storing of the source files in
>>> …/distfiles?
>> 
>> No [...]
> 
> Are there side-effects to cleaning out that directory manually, other than 
> re-downloading when needed?

It's largely fine. My housekeeping script (available in the repository) removes 
old distfiles. "port reclaim" should as well, IIUC.

If you have any unclean ports where you have completed the fetch phase but have 
not completed the extract phase, the extract phase will fail because it cannot 
find the distfile. The solution would be to clean the port and try again.


___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Ryan Schmidt]

On Jan 19, 2015, at 5:34 AM, René J.V. Bertin wrote:

> On Monday January 19 2015 04:07:40 Ryan Schmidt wrote:
> 
>> There are situations where MacPorts will advise you that an installation you 
>> requested cannot proceed until you deactivate (or uninstall) a particular 
>> port (the conflicts_build portgroup). Making deactivation impossible would 
>> be inconvenient in those cases.
> 
> Does deactivation become impossible when the software/foo/tarball has been 
> removed?

No, but re-activation would be impossible, therefore deactivation should be 
prevented.

> Are the contents of that tarball used to determine which files to remove, for 
> instance?

No, that's stored in the registry.


 apt-get is not typically used on OS X, which is the platform where 
 concerns regarding Spotlight and Time Machine occur. It would be more 
 interesting to compare against the other OS X package managers, Homebrew 
 or Fink.
> 
> What issues with SpotLight and/or Time Machine? 

Spotlight would find items in the /opt/local/var/macports/software directory. 
So when you were trying to launch an application in /Applications/MacPorts, it 
might find the copy in /opt/local/var/macports/software instead, which might 
not work.

Time Machine would back up two copies of each item -- the real one in 
/opt/local and the one in /opt/local/var/macports/software -- because Time 
Machine doesn't understand hard links (which is not Time Machine's fault; hard 
links are designed to look just like independent files).


> If there are, it would be possible to provide a port command or script that 
> adds certain directories to their respective exclusion lists. AFAIK that can 
> be done from the commandline and thus also from scripts.

That would be a possible solution for the Spotlight issues but not for the Time 
Machine issues.


>> It's relevant if we're discussing why MacPorts was changed to work the way 
>> it does today. It's not relevant provided you're willing to opt out of being 
>> able to deactivate a port.
> 
> IMHO, suggesting an option for MacPorts not to support 
> deactivation/activation is like suggesting that feature as an option to 
> apt/dpkg.

I agree code could be written to add this option to MacPorts. But someone would 
have to write and test that code. The assumption that archives exist is 
pervasive in MacPorts; I suspect code changes would be needed throughout base. 
And I am not convinced this extensive effort is worthwhile, given the drawbacks 
making use of this option, that have been discussed in this thread, would 
entail. I agree that reducing disk usage is good, but I don't think trying to 
make /opt/local/var/macports/software optional is the best way to achieve that. 
The "port reclaim" command which will be in MacPorts 2.4 is an effort at 
letting you reclaim unnecessarily used disk space. There are probably 
additional ways in which it could help you in that regard, and we should 
continue to improve it in the future.


> What could be an option:
> - remove inactivated ports by default after a port upgrade

You can use the "-u" flag when you run "sudo port upgrade" (i.e. "sudo port -u 
upgrade"), but it cannot currently be made the default. You could create a 
shell function to do that.

> - use xz instead of bzip2 to compact things a bit more

Whatever compression format is used needs to be supported without the use of 
any port. OS X does not include support for dealing with xz files, which is one 
reason why bz2 files were chosen instead. Changing this would involve bundling 
a copy of the xz utilities with MacPorts; changing the default archive format 
from bz2 to xz in archive_sites.conf and macports.conf; re-building all ports 
on all buildbot builders with this new version of MacPorts; and upgrading all 
users to this new version of MacPorts. I also do not know what would happen if 
a user who already has ports installed with bz2 archives suddenly changes the 
archive format to xz (or, more generally, makes any change to the archive 
format). Would MacPorts still know how to find the existing archive and remove 
it when a port is uninstalled or upgraded?

> - the place where such large things are stored, which are required only when 
> doing port maintenance or development.

The software directory is used during normal port installation. You could 
possibly symlink it to another drive if space is tight on your main drive; I 
haven't tested this thoroughly to know if it works well enough.


> That latter option would also allow using a case-sensitive fs for the 
> build/work directories, which could be beneficial (e.g. make post-extract 
> adaptations to a case-insensitive target fs possible).

Let's not bring case sensitivity into this discussion, which is about 
reclaiming disk space. MacPorts can be installed on case-sensitive systems and 
on case-insensitive systems, but it is a bad idea to have a single MacPorts 
installation try to interact with both types of filesystems

Re: /opt/local/macports/software

[Ian Wadham]

I agree with *both* Daniel and René.

On 20/01/2015, at 7:08 AM, René J.V. Bertin wrote:
> On Monday January 19 2015 14:35:19 Daniel J. Luke wrote:
> 
>> I actually prefer doing `port upgrade outdated` make sure things are working 
>> as I expect (and if not, quickly revert back with deactivate/activate) and 
>> then `port uninstall inactive`
>> 
>> activate/deactivate is a /really nice/ feature that MacPorts offers.

The ability to revert if you get a dud version from upstream is great.  It is
also good for checking details of "before" and "after" when an upstream
bug is claimed to have been fixed… ;-)

> Me too, though I wouldn't mind an automatic option that leaves say
> the 2 latest inactive versions, except for ports on an exclusion list.

N inactive versions can be simplistic if there have been MacPorts-based
revisons (i.e. the trailing number "_n" has changed).

I think one needs to keep the last version that came from upstream (i.e. the
last "point" version), e.g. keep 4.13.3_1, 4.14.4_0, 4.14.4_1 (active), but
drop 4.13.3_0 and earlier versions.

> Dream on :)

Actually I was planning to implement something like that in my Fossick
GUI app for MacPorts, which has lain around unloved for a while, but
I suppose a script that does it would be not too difficult.

Cheers, Ian W.


___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Daniel J. Luke]

> On Jan 19, 2015, at 4:43 PM, Clemens Lang  wrote:
> - On 19 Jan, 2015, at 22:20, Daniel J. Luke dl...@geeklair.net wrote:
>> ... but you're right, cal fixed it and it's been released (I though the fix 
>> was
>> sitting on trunk still, but it made Macports 2.3.0)
> 
> I am currently not aware of any problems with /opt or /opt/local being a 
> symlink
> except for the port provides thing. I did test trace mode with a symlinked
> prefix to make sure it works and I consider anything that breaks this 
> behavior a
> bug I'd be willing to fix.

cool, that's good to know.

I'm still looking forward to when we run trace mode all the time by default.

> I even wrote a draft implementation of a fix for port provides, but nobody
> picked up on it, finished it and committed it (or provided a commit-ready 
> patch).
> If somebody wants to do that, the implementation is somewhere in the -dev 
> mailing
> list archives.

yeah, I had some time to look at it when I first posted to the -dev list about 
it, but no one responded and I haven't had time to mess with it since then.

--
Daniel J. Luke  
 
++  
  
| * dl...@geeklair.net * |  

| *-- http://www.geeklair.net -* |  

++  
  
|   Opinions expressed are mine and do not necessarily   |  

|  reflect the opinions of my employer.  |  

++




___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Clemens Lang]

- On 19 Jan, 2015, at 22:20, Daniel J. Luke dl...@geeklair.net wrote:

> ... but you're right, cal fixed it and it's been released (I though the fix 
> was
> sitting on trunk still, but it made Macports 2.3.0)

I am currently not aware of any problems with /opt or /opt/local being a symlink
except for the port provides thing. I did test trace mode with a symlinked
prefix to make sure it works and I consider anything that breaks this behavior a
bug I'd be willing to fix.

I even wrote a draft implementation of a fix for port provides, but nobody
picked up on it, finished it and committed it (or provided a commit-ready 
patch).
If somebody wants to do that, the implementation is somewhere in the -dev 
mailing
list archives.

-- 
Clemens Lang
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Daniel J. Luke]

> On Jan 19, 2015, at 4:14 PM, René J.V. Bertin  wrote:
>> One needs to set portdbpath in macports.conf to the 'real' path
> 
> Oh? I haven't, and I also don't see why it'd be required.

I was thinking of https://trac.macports.org/ticket/39850

> There has been a time where this kind of configuration obliged one to 
> deactivate sandboxing (trac #39850), but that issue has been solved.

well, as mentioned in #39850 setting portdbpath let you run with a symlink 
without deactivating sandboxing.

... but you're right, cal fixed it and it's been released (I though the fix was 
sitting on trunk still, but it made Macports 2.3.0)

--
Daniel J. Luke  
 
++  
  
| * dl...@geeklair.net * |  

| *-- http://www.geeklair.net -* |  

++  
  
|   Opinions expressed are mine and do not necessarily   |  

|  reflect the opinions of my employer.  |  

++



___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[René J . V . Bertin]

On Monday January 19 2015 15:58:08 Daniel J. Luke wrote:

> it mostly works (port provides doesn't, for now),

(echo, echo, e c h o :))

> One needs to set portdbpath in macports.conf to the 'real' path

Oh? I haven't, and I also don't see why it'd be required.

I think that for my 1st MacPorts install on 10.6, I used the defaults, and then 
moved the whole tree, making /opt/local a symlink.
Then after upgrading to 10.9, I followed the migration guide without bothering 
to change anything. Or rather, I changed the target of the symlink, so I could 
have the 10.6 and 10.9 versions side by side on the same "data" partition, with 
the appropriate symlink on 10.6 and 10.9 boot partitions.

There has been a time where this kind of configuration obliged one to 
deactivate sandboxing (trac #39850), but that issue has been solved.

R.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[René J . V . Bertin]

On Monday January 19 2015 15:25:17 Brandon Allbery wrote:

> /opt/local itself can't be safely symlinked because various things break
> when it's not a real directory. Certain parts of things underneath it very

Like what? /opt/local has always been a symlink for me, and the only thing I'm 
aware of that doesn't work is `port provides`.
But when I brought that up it was esteemed that the symlink wasn't the cause 
for that.

R.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Daniel J. Luke]

> On Jan 19, 2015, at 3:08 PM, René J.V. Bertin  wrote:
> Me too, though I wouldn't mind an automatic option that leaves say the 2 
> latest inactive versions, except for ports on an exclusion list.
> 
> Dream on :)

I would be willing to bet that something like that would be included in 
MacPorts if only someone bothered to code it ;-)

--
Daniel J. Luke  
 
++  
  
| * dl...@geeklair.net * |  

| *-- http://www.geeklair.net -* |  

++  
  
|   Opinions expressed are mine and do not necessarily   |  

|  reflect the opinions of my employer.  |  

++



___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Daniel J. Luke]

> On Jan 19, 2015, at 3:25 PM, Brandon Allbery  wrote:
> 
> On Mon, Jan 19, 2015 at 3:12 PM, René J.V.  wrote:
> > On the other hand, I solved it by copying most of /opt/local/var/macports
> > onto an external USB drive and symlinking it back. Huge USB external drives
> > are ridiculously cheap these days.
> 
> I'm pretty sure I tried that, and got slapped on the fingers with references 
> to security, sandboxing, and the like.
> 
> /opt/local itself can't be safely symlinked because various things break when 
> it's not a real directory.

it mostly works (port provides doesn't, for now), but I run it this way on a 
machine for test purposes to make sure it keeps working (actually my /opt is a 
symlink). One needs to set portdbpath in macports.conf to the 'real' path, but 
it does work to use a symlink to keep prefix the same (so that you can still 
use MacPorts provided binaries).

You can, of course, also just install MacPorts in an alternate prefix (which is 
very much supported) - you just need to install from source and you loose the 
ability to use the MacPorts provided binaries.

> Certain parts of things underneath it very much can be without problems; I 
> moved the build tree, sources, and distfiles. (The build tree was the only 
> thing that worried me, and probably trace mode won't work that way --- but 
> then, I'm unlikely to use trace mode on the Air.)

I haven't tested trace mode with my symlink'd config, so it's possible that it 
doesn't work.

--
Daniel J. Luke  
 
++  
  
| * dl...@geeklair.net * |  

| *-- http://www.geeklair.net -* |  

++  
  
|   Opinions expressed are mine and do not necessarily   |  

|  reflect the opinions of my employer.  |  

++




___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Mike Savory]

My solution for having extra storage on a macbook is one of these
   http://minidrive.bynifty.com 
It has given me an extra 64G (of slow storage, but immediately available) for a 
couple of years now. For $100US I am about to upgrade it to use a 128G micro SD.

Mike
(I still run Macports on my main partition, but can offload other 
documents/music to the other drive)

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Vincent Habchi]

> On 19 Jan 2015, at 20:13, Craig Treleaven  wrote:
> 
> If one has a too-small SSD, it seems more-than-a-little strange to complain 
> that building/installing a bunch of software packages consumes it.  Get a 
> bigger drive.  Or smaller expectations.

Personally, when I bought my MacBook Air two years ago, I had a few spare bucks 
and had the choice between {a bigger SSD} or {a faster CPU and 8 GB RAM}.

I chose the latter, and stuck with a 128 MB SSD.

Vincent

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Chris Jones]

Hi,

> On 19 Jan 2015, at 8:28 pm, René J.V. Bertin  wrote:
> 
> On Monday January 19 2015 20:20:06 Chris Jones wrote:
> 
>>> If one has a too-small SSD, it seems more-than-a-little strange to complain 
>>> that building/installing a bunch of software packages consumes it.  Get a 
>>> bigger drive.  Or smaller expectations.
>> 
>> And how pray does one do that in a Mac Book with non-upgradable Solid state 
>> storage...
> 
> Getting smaller expectations is impossible for Mac owners, then? :P

I had obviously ignored that part of the reply as 'not a sensible solution'...

> 
> Seriously, there are reasons to cast a wallet-vote against certain products. 
> Absence of upgradable/replaceable memory (volatile and non-volatile) are 
> among the main reasons (though only just before absence of ethernet).

It might surprise you but I personally agree with Apple's direction here, but 
we are going OT. It is what it is, and despite what some think minimising disk 
usage is a reality for a lot of people.

Chris

> 
> R.
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[René J . V . Bertin]

On Monday January 19 2015 20:20:06 Chris Jones wrote:

> Nope. Saving disk space when not required is always a good idea.

Just to be clear: I do agree with this, and practice it myself. One of the 
reasons MacPorts is not installed on my boot partition.
(heck, I'm old and pedantic enough to care about free space fragmentation ...)

R
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[René J . V . Bertin]

On Monday January 19 2015 20:20:06 Chris Jones wrote:

> > If one has a too-small SSD, it seems more-than-a-little strange to complain 
> > that building/installing a bunch of software packages consumes it.  Get a 
> > bigger drive.  Or smaller expectations.
> 
> And how pray does one do that in a Mac Book with non-upgradable Solid state 
> storage...

Getting smaller expectations is impossible for Mac owners, then? :P

Seriously, there are reasons to cast a wallet-vote against certain products. 
Absence of upgradable/replaceable memory (volatile and non-volatile) are among 
the main reasons (though only just before absence of ethernet).

R.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Brandon Allbery]

On Mon, Jan 19, 2015 at 3:12 PM, René J.V.  wrote:

> > On the other hand, I solved it by copying most of /opt/local/var/macports
> > onto an external USB drive and symlinking it back. Huge USB external
> drives
> > are ridiculously cheap these days.
>
> I'm pretty sure I tried that, and got slapped on the fingers with
> references to security, sandboxing, and the like.
>

/opt/local itself can't be safely symlinked because various things break
when it's not a real directory. Certain parts of things underneath it very
much can be without problems; I moved the build tree, sources, and
distfiles. (The build tree was the only thing that worried me, and probably
trace mode won't work that way --- but then, I'm unlikely to use trace mode
on the Air.)

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Chris Jones]

Hi,

> On 19 Jan 2015, at 7:13 pm, Craig Treleaven  wrote:
> 
> At 3:11 PM + 1/19/15, Chris Jones wrote:
>> ...
> 
> Does anyone else find it bizarre that, in 2015, we've got such an active 
> thread about saving a few gigs of space?

Nope. Saving disk space when not required is always a good idea.

> 
> If one has a too-small SSD, it seems more-than-a-little strange to complain 
> that building/installing a bunch of software packages consumes it.  Get a 
> bigger drive.  Or smaller expectations.

And how pray does one do that in a Mac Book with non-upgradable Solid state 
storage...

> 
> Having archives where one can activate/deactivate in moments is an awesome 
> feature.  Upgrade go bad?  Switch back in moments.  Need multiple versions of 
> a package with conflicting variants, switch in seconds.  Etc.
> 
> It would be folly to remove such a fantastic feature to cater to a few 
> space-constrained users.

No one to my knowledge has suggested that. Just that it should be an *option*...

> 
> Craig
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[René J . V . Bertin]

On Monday January 19 2015 14:52:25 Brandon Allbery wrote:

> On the other hand, I solved it by copying most of /opt/local/var/macports
> onto an external USB drive and symlinking it back. Huge USB external drives
> are ridiculously cheap these days.

I'm pretty sure I tried that, and got slapped on the fingers with references to 
security, sandboxing, and the like.

The only time I managed to have at least the build dir mounted from elsewhere 
was when experimenting with ZFS for which I'd kept a good part of my 1TB 
internal. Created a dataset mounted on /opt/local/var/macports/build (with 
/opt/local a symlink; ZFS doesn't care), switched on compression on the 
dataset, and ho presto.
Except that ZFS is (still) so unstable that it has a habit of causing KPs even 
when you're not using it, so that experiment ended quite quickly.

Compression would be really great on something like a build tree; object code 
tends to compress even better than source code.

R.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Akim Demaille]

> Le 19 janv. 2015 à 20:13, Craig Treleaven  a écrit :
> 
> At 3:11 PM + 1/19/15, Chris Jones wrote:
>> ...
> 
> Does anyone else find it bizarre that, in 2015, we've got such an 
> active thread about saving a few gigs of space?
> 
> If one has a too-small SSD, it seems more-than-a-little strange to 
> complain that building/installing a bunch of software packages 
> consumes it.  Get a bigger drive.  Or smaller expectations.

Thanks for the tip!  One will think about revising his idea of
how space should be used.  Actually, he shouldn't care either
about CPU, they are getting s fast these days!

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[René J . V . Bertin]

On Monday January 19 2015 14:35:19 Daniel J. Luke wrote:

> personally, I have had to restore machines in places where connectivity was 
> problematic before - and I size things so I have more than enough backup 
> capacity to just back up everything and save myself the potential headaches 
> (lessons learned over time). Your needs may be different.

I'm not saying I have only a TM backup ... ;)


> I actually prefer doing `port upgrade outdated` make sure things are working 
> as I expect (and if not, quickly revert back with deactivate/activate) and 
> then `port uninstall inactive`
> 
> activate/deactivate is a /really nice/ feature that MacPorts offers.

Me too, though I wouldn't mind an automatic option that leaves say the 2 latest 
inactive versions, except for ports on an exclusion list.

Dream on :)

R.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Brandon Allbery]

On Mon, Jan 19, 2015 at 2:13 PM, Craig Treleaven 
wrote:

> Does anyone else find it bizarre that, in 2015, we've got such an active
> thread about saving a few gigs of space?
>
> If one has a too-small SSD, it seems more-than-a-little strange to
> complain that building/installing a bunch of software packages consumes
> it.  Get a bigger drive.  Or smaller expectations.
>

On the one hand, I run MacPorts on my 2011 MacBook Air and yes, the SSD is
always a size issue.

On the other hand, I solved it by copying most of /opt/local/var/macports
onto an external USB drive and symlinking it back. Huge USB external drives
are ridiculously cheap these days.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Craig Treleaven]

At 3:11 PM + 1/19/15, Chris Jones wrote:

...


Does anyone else find it bizarre that, in 2015, we've got such an 
active thread about saving a few gigs of space?


If one has a too-small SSD, it seems more-than-a-little strange to 
complain that building/installing a bunch of software packages 
consumes it.  Get a bigger drive.  Or smaller expectations.


Having archives where one can activate/deactivate in moments is an 
awesome feature.  Upgrade go bad?  Switch back in moments.  Need 
multiple versions of a package with conflicting variants, switch in 
seconds.  Etc.


It would be folly to remove such a fantastic feature to cater to a 
few space-constrained users.


Craig
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Daniel J. Luke]

> On Jan 19, 2015, at 10:49 AM, René J.V. Bertin  wrote:
> On Monday January 19 2015 09:34:51 Daniel J. Luke wrote:
>> being able to let TimeMachine back up my macports $prefix is nice, I 
>> wouldn't want to not be able to do that because of a macports design 
>> decision.
> 
> Of course - but all of it? I exclude a good part of $prefix/var/macports, 
> because it's too big and so much of it can be regenerated/redownloaded.

personally, I have had to restore machines in places where connectivity was 
problematic before - and I size things so I have more than enough backup 
capacity to just back up everything and save myself the potential headaches 
(lessons learned over time). Your needs may be different.

>> man port says:
>> 
>> -u   uninstall non-active ports when upgrading and uninstalling
> 
> Yup. Can it be made the default (like -c can)?

not that I know of.

I actually prefer doing `port upgrade outdated` make sure things are working as 
I expect (and if not, quickly revert back with deactivate/activate) and then 
`port uninstall inactive`

activate/deactivate is a /really nice/ feature that MacPorts offers.

>>> - the place where such large things are stored, which are required only 
>>> when doing port maintenance or development.
>> 
>> you can set portdbpath in macports.conf (which would move some other stuff 
>> too).
> 
> Good to know; it's not a name I'd be looking for!
> 
>>> Similarly, is there a way to disable the storing of the source files in
>>> …/distfiles?
>> 
>> No [...]
> 
> Are there side-effects to cleaning out that directory manually, other than 
> re-downloading when needed?

distfiles are fine to remove, as far as I know.
--
Daniel J. Luke  
 
++  
  
| * dl...@geeklair.net * |  

| *-- http://www.geeklair.net -* |  

++  
  
|   Opinions expressed are mine and do not necessarily   |  

|  reflect the opinions of my employer.  |  

++



___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Clemens Lang]

- On 19 Jan, 2015, at 16:49, René J.V. Bertin rjvber...@gmail.com wrote:

>> > Similarly, is there a way to disable the storing of the source files in
>> > …/distfiles?
>> 
>> No [...]
> 
> Are there side-effects to cleaning out that directory manually, other than
> re-downloading when needed?

I'm not aware of any. It's usually safe to do, since MacPorts doesn't keep any
metadata on it.

-- 
Clemens Lang
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[René J . V . Bertin]

On Monday January 19 2015 09:34:51 Daniel J. Luke wrote:

> being able to let TimeMachine back up my macports $prefix is nice, I wouldn't 
> want to not be able to do that because of a macports design decision.

Of course - but all of it? I exclude a good part of $prefix/var/macports, 
because it's too big and so much of it can be regenerated/redownloaded.

> man port says:
> 
> -u   uninstall non-active ports when upgrading and uninstalling

Yup. Can it be made the default (like -c can)?

> > - the place where such large things are stored, which are required only 
> > when doing port maintenance or development.
> 
> you can set portdbpath in macports.conf (which would move some other stuff 
> too).

Good to know; it's not a name I'd be looking for!

> > Similarly, is there a way to disable the storing of the source files in
> > …/distfiles?
> 
> No [...]

Are there side-effects to cleaning out that directory manually, other than 
re-downloading when needed?

R.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Vincent Habchi]

Clemens:

> I disagree. I often use deactivation and activation, and I'd have to 
> re-download
> the archive every time I did that, it would be a major hassle for me.

I agree. Of course, your mileage may vary. That’s why I think it’d mayhap be 
worth investigating the possibility of having more than one directory to 
retrieve the archives from. This way, you could easily swap the files out of 
the SSD to an external drive, that you’d connect in case you’d need one of the 
files backed up there.

> No, but there is going to be `port reclaim` in 2.4, that deletes files you no
> longer need. Give it a try if you're running trunk, it could easily free up a
> gigabyte or two.

Will do that tonight. Great news! Thanks.

Vincent


___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Chris Jones]

But I admit it is not very useful nowadays. It should be optional, at least when
the version installed is the default one, i.e. the binary can be re-downloaded
verbatim from the server (not a bespoken version with various variants set).


I disagree. I often use deactivation and activation, and I'd have to re-download
the archive every time I did that, it would be a major hassle for me.


The idea was it would be optional to keep or not keep the archive...

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Chris Jones]

It is also correct that all other package systems you're familiar with
never have to build locally from source.


True, but I don't agree it completely negates the argument.


Possibly if you can get away with always operating in binary mode then
we could re-download missing archives from packages.macports.org
, If you can't (and there are lots of
reasons why things might not be be prebuilt for you) then you really
want those archives.


That is a choice a user might wish to make for themselves... If they 
have limited disk space then even for packages without binary archives a 
user might prefer to accept the CPU cost of re-building from source, if 
they ever need to, to keeping the archive on disk just in case...


Chris

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Clemens Lang]

- On 19 Jan, 2015, at 15:40, Vincent Habchi vi...@macports.org wrote:

> But I admit it is not very useful nowadays. It should be optional, at least 
> when
> the version installed is the default one, i.e. the binary can be re-downloaded
> verbatim from the server (not a bespoken version with various variants set).

I disagree. I often use deactivation and activation, and I'd have to re-download
the archive every time I did that, it would be a major hassle for me.


> Similarly, is there a way to disable the storing of the source files in
> …/distfiles?

No, but there is going to be `port reclaim` in 2.4, that deletes files you no
longer need. Give it a try if you're running trunk, it could easily free up a
gigabyte or two.

-- 
Clemens Lang
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Brandon Allbery]

On Mon, Jan 19, 2015 at 4:42 AM, Chris Jones 
wrote:

> It is correct that all others I am familiar with do not require the user
> to effectively have two copies (albeit one compressed) on their system, the
> installed one and the original install media (whether that be tar, rpm, deb
> or whatever).
>

It is also correct that all other package systems you're familiar with
never have to build locally from source.

Possibly if you can get away with always operating in binary mode then we
could re-download missing archives from packages.macports.org, If you can't
(and there are lots of reasons why things might not be be prebuilt for you)
then you really want those archives.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Vincent Habchi]

Oops, not ‘bespoken’, ‘bespoke’.
‘it was well worth keeping a local copy RATHER than to trust a flaky remote 
server or a rickety connexion.’

Who said I needed a proofreader? :)

V.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Vincent Habchi]

Salut Akim ! Hi Ryan!

> I'm talking about removing the copy kept in that directory at the
> end of the process.

I suppose this is a leftover from the time when Internet bandwidth was 
unreliable and expensive, and it was well worth keeping a local copy than to 
trust a flaky remote server or a rickety connexion.

Personally, I’m in the same case as Akim. What I do is that I regularly backup 
the contents of the directory on some external USB drive (in fact, I even do it 
twice, one manually and one automatically through Time Machine) and then if 
ever I get struck in a mire, I restore it.

But I admit it is not very useful nowadays. It should be optional, at least 
when the version installed is the default one, i.e. the binary can be 
re-downloaded verbatim from the server (not a bespoken version with various 
variants set). 

Similarly, is there a way to disable the storing of the source files in 
…/distfiles?

Cheers! (À bientôt Akim!)
Vincent

PS: Maybe it would be nice to be able to specify alternate directories for 
archives, so that one could precisely backup (or move) the directory on some 
external disk, and then restore from it, if need be.


___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Daniel J. Luke]

> On Jan 19, 2015, at 6:34 AM, René J.V. Bertin  wrote:
> What issues with SpotLight and/or Time Machine? 

the best way to figure that out would probably be to look through the 
macports-dev archives where the changes were discussed before they were 
implemented.

Also note that the way our binary packages work was tied into this change 
(along with the desire to continue to provide activate/deactivate for multiple 
versions of a port).

> If there are, it would be possible to provide a port command or script that 
> adds certain directories to their respective exclusion lists. AFAIK that can 
> be done from the commandline and thus also from scripts.

being able to let TimeMachine back up my macports $prefix is nice, I wouldn't 
want to not be able to do that because of a macports design decision.

> What could be an option:
> - remove inactivated ports by default after a port upgrade

man port says:

-u   uninstall non-active ports when upgrading and uninstalling

> - use xz instead of bzip2 to compact things a bit more

this would probably be a small change (I think there's support for gzip and zip 
already) - but changing your local archive type means you won't get binary 
archives.

It would be interesting to see if changing to xz would be worthwhile on a 
'typical' set of ports (or on the un-typical set of ports that are available as 
binary archives).

> - the place where such large things are stored, which are required only when 
> doing port maintenance or development.

you can set portdbpath in macports.conf (which would move some other stuff too).

--
Daniel J. Luke  
 
++  
  
| * dl...@geeklair.net * |  

| *-- http://www.geeklair.net -* |  

++  
  
|   Opinions expressed are mine and do not necessarily   |  

|  reflect the opinions of my employer.  |  

++



___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Chris Jones]

Well, I'm a grownup and willing to take these chances.  I don't
play with activate/deactivate.  I know of no other distros that
"wastes" that kind of disk space for that.  That some wish to
use this feature, fine.  But I need those gigs back.


Removing these files will very likely break your upgrade to the next
MacPorts version. The upgrade process will run a script that uses a
condition you fulfilled by removing these files to trigger more work,
which will fail because you're not actually in the situation the
script expects you to be.

You'll get to keep the pieces.

TL;DR: These files are needed. Do not remove them. Do not tamper with
MacPorts' internals.


I agree right now is a bad idea to manually nuke these files, and it 
should not be done.


I also though agree with the OP its valid to question why it is really 
needed, as it is a bit of a resource waste for some people.


I also think that comparing MP to *both* other OSX package managers, and 
other OSes, are both valid and interesting comparisons to make.


cheers Chris
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Clemens Lang]

Hi,

- On 19 Jan, 2015, at 10:26, Akim Demaille a...@lrde.epita.fr wrote:

> Well, I'm a grownup and willing to take these chances.  I don't
> play with activate/deactivate.  I know of no other distros that
> "wastes" that kind of disk space for that.  That some wish to
> use this feature, fine.  But I need those gigs back.

Removing these files will very likely break your upgrade to the next
MacPorts version. The upgrade process will run a script that uses a
condition you fulfilled by removing these files to trigger more work,
which will fail because you're not actually in the situation the
script expects you to be.

You'll get to keep the pieces.

TL;DR: These files are needed. Do not remove them. Do not tamper with
MacPorts' internals.

-- 
Clemens Lang
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Akim Demaille]

> Le 19 janv. 2015 à 11:07, Ryan Schmidt  a écrit :
> 
> On Jan 19, 2015, at 3:59 AM, Akim Demaille wrote:
>> You're talking implementation details, I'm talking feature.  And the
>> implementation is straightforward: rm -f /opt/local/macports/software/
>> when  was activated.
> 
> It's quite a lot more than just that. You're asking for a way for the user to 
> opt in to auto-removal of archives and opt out of the ability to use the 
> deactivate feature. MacPorts currently relies on the deactivate feature 
> during uninstallation, so there would be changes required there as well.

You are right.

>> Yes, I'm sure it's nice.  I'm not saying the feature is useless, I'm
>> saying I don't want to use it.
> 
> There are situations where MacPorts will advise you that an installation you 
> requested cannot proceed until you deactivate (or uninstall) a particular 
> port (the conflicts_build portgroup). Making deactivation impossible would be 
> inconvenient in those cases.

Well, AFAICT, it basically amounts to s/deactivate/uninstall/ in the
error messages.

> 
> 
>>> apt-get is not typically used on OS X, which is the platform where concerns 
>>> regarding Spotlight and Time Machine occur. It would be more interesting to 
>>> compare against the other OS X package managers, Homebrew or Fink.
>> 
>> I don't see how the OS is relevant in anyway here.
> 
> It's relevant if we're discussing why MacPorts was changed to work the way it 
> does today. It's not relevant provided you're willing to opt out of being 
> able to deactivate a port.

I'm not suggesting to change anything in the way its builds, installs,
activates anything.  This is robust, works well, there's no reason to
take chances with that part of the code.

I'm talking about removing the copy kept in that directory at the
end of the process.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Ryan Schmidt]

On Jan 19, 2015, at 3:59 AM, Akim Demaille wrote:
> 
> Le 19 janv. 2015 à 10:54, Ryan Schmidt a écrit :
>>> So maybe we could reconsider the existence of this feature, or at least,
>>> the fact that its mandatory.
>> 
>> If I remember correctly, the code for the old way with hard links was 
>> removed from MacPorts. There is no way to go back to that method, without 
>> rewriting the code.
> 
> You're talking implementation details, I'm talking feature.  And the
> implementation is straightforward: rm -f /opt/local/macports/software/
> when  was activated.

It's quite a lot more than just that. You're asking for a way for the user to 
opt in to auto-removal of archives and opt out of the ability to use the 
deactivate feature. MacPorts currently relies on the deactivate feature during 
uninstallation, so there would be changes required there as well.


>>> Well, apt-get and the rest have no such equivalent.  They just deploy
>>> the software, period.  They don't keep a copy at hand, just in case.
>>> And yes, there's no acivate/deactivate (that I know of).
>> 
>> If your installed files have become damaged, for example because a 
>> third-party installer overwrote them, it's very nice to be able to fix it by 
>> simply deactivating and re-activating the port.
> 
> Yes, I'm sure it's nice.  I'm not saying the feature is useless, I'm
> saying I don't want to use it.

There are situations where MacPorts will advise you that an installation you 
requested cannot proceed until you deactivate (or uninstall) a particular port 
(the conflicts_build portgroup). Making deactivation impossible would be 
inconvenient in those cases.


>> apt-get is not typically used on OS X, which is the platform where concerns 
>> regarding Spotlight and Time Machine occur. It would be more interesting to 
>> compare against the other OS X package managers, Homebrew or Fink.
> 
> I don't see how the OS is relevant in anyway here.

It's relevant if we're discussing why MacPorts was changed to work the way it 
does today. It's not relevant provided you're willing to opt out of being able 
to deactivate a port.


___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Akim Demaille]

> Le 19 janv. 2015 à 10:54, Ryan Schmidt  a écrit :
>> So maybe we could reconsider the existence of this feature, or at least,
>> the fact that its mandatory.
> 
> If I remember correctly, the code for the old way with hard links was removed 
> from MacPorts. There is no way to go back to that method, without rewriting 
> the code.

You're talking implementation details, I'm talking feature.  And the
implementation is straightforward: rm -f /opt/local/macports/software/
when  was activated.

>> Well, apt-get and the rest have no such equivalent.  They just deploy
>> the software, period.  They don't keep a copy at hand, just in case.
>> And yes, there's no acivate/deactivate (that I know of).
> 
> If your installed files have become damaged, for example because a 
> third-party installer overwrote them, it's very nice to be able to fix it by 
> simply deactivating and re-activating the port.

Yes, I'm sure it's nice.  I'm not saying the feature is useless, I'm
saying I don't want to use it.

> apt-get is not typically used on OS X, which is the platform where concerns 
> regarding Spotlight and Time Machine occur. It would be more interesting to 
> compare against the other OS X package managers, Homebrew or Fink.

I don't see how the OS is relevant in anyway here.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Ryan Schmidt]

On Jan 19, 2015, at 3:42 AM, Akim Demaille wrote:
> 
>> Le 19 janv. 2015 à 10:34, Ryan Schmidt a écrit :
>> 
>> Please Reply All so that the discussion stays on the mailing list.
> 
> Hmmm, I did.
> 
>> Of note is that MacPorts used to not do this, or rather, using these 
>> archives used to be optional, and not the default. Previously, the default 
>> was that the contents of /opt/local/var/macports/software was the actual 
>> software being installed. Hard links would then be created in the "real" 
>> locations. This did not waste disk space, however various new features of OS 
>> X interacted badly with this, including Spotlight as of OS X v10.4 and Time 
>> Machine as of OS X v10.5, so we were forced to remove the previous mode of 
>> operation and insist on using archives instead.
> 
> OK.
> 
> So maybe we could reconsider the existence of this feature, or at least,
> the fact that its mandatory.

If I remember correctly, the code for the old way with hard links was removed 
from MacPorts. There is no way to go back to that method, without rewriting the 
code.

>> I am not familiar with what other package management systems do.
> 
> Well, apt-get and the rest have no such equivalent.  They just deploy
> the software, period.  They don't keep a copy at hand, just in case.
> And yes, there's no acivate/deactivate (that I know of).

If your installed files have become damaged, for example because a third-party 
installer overwrote them, it's very nice to be able to fix it by simply 
deactivating and re-activating the port.

apt-get is not typically used on OS X, which is the platform where concerns 
regarding Spotlight and Time Machine occur. It would be more interesting to 
compare against the other OS X package managers, Homebrew or Fink.


___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Chris Jones]

On 19/01/15 09:34, Ryan Schmidt wrote:

Please Reply All so that the discussion stays on the mailing list.


On Jan 19, 2015, at 3:26 AM, Akim Demaille wrote:


Le 19 janv. 2015 à 09:27, Ryan Schmidt a écrit :


Hi Ryan,


If you mean /opt/local/var/macports/software, that's where the compressed 
archives of all your installed ports are stored. You are not meant to interact 
with this directory manually. To remove an archive from this directory, 
uninstall the corresponding port. If you're still using the port and don't wish 
to uninstall it, then you should not delete the corresponding archive in this 
directory, or you won't be able to re-activate the port if you deactivate it. 
There may be other aspects of MacPorts that also assume you have not tampered 
with the contents of this directory.


Well, I'm a grownup and willing to take these chances.  I don't
play with activate/deactivate.  I know of no other distros that
"wastes" that kind of disk space for that.  That some wish to
use this feature, fine.  But I need those gigs back.


Of note is that MacPorts used to not do this, or rather, using these archives used to be 
optional, and not the default. Previously, the default was that the contents of 
/opt/local/var/macports/software was the actual software being installed. Hard links 
would then be created in the "real" locations. This did not waste disk space, 
however various new features of OS X interacted badly with this, including Spotlight as 
of OS X v10.4 and Time Machine as of OS X v10.5, so we were forced to remove the previous 
mode of operation and insist on using archives instead.

I am not familiar with what other package management systems do.


It is correct that all others I am familiar with do not require the user 
to effectively have two copies (albeit one compressed) on their system, 
the installed one and the original install media (whether that be tar, 
rpm, deb or whatever).


So I think it is a reasonable question as to why MP requires this. My 
SSD is quite big, so space does not concern me particularly, but also I 
very rarely activate/deactivate (I would guess I am not that different 
to a lot of users here) and thus could easily give this option up. If I 
remove something then decide I want it back, well I have to re-download 
the binary tarball or rebuild it.


I think keeping these tarballs should be made optional again, in some way...

Chris

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Akim Demaille]

> Le 19 janv. 2015 à 10:34, Ryan Schmidt  a écrit :
> 
> Please Reply All so that the discussion stays on the mailing list.

Hmmm, I did.

> Of note is that MacPorts used to not do this, or rather, using these archives 
> used to be optional, and not the default. Previously, the default was that 
> the contents of /opt/local/var/macports/software was the actual software 
> being installed. Hard links would then be created in the "real" locations. 
> This did not waste disk space, however various new features of OS X 
> interacted badly with this, including Spotlight as of OS X v10.4 and Time 
> Machine as of OS X v10.5, so we were forced to remove the previous mode of 
> operation and insist on using archives instead.

OK.

So maybe we could reconsider the existence of this feature, or at least,
the fact that its mandatory.

> I am not familiar with what other package management systems do.

Well, apt-get and the rest have no such equivalent.  They just deploy
the software, period.  They don't keep a copy at hand, just in case.
And yes, there's no acivate/deactivate (that I know of).
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Ryan Schmidt]

Please Reply All so that the discussion stays on the mailing list.

> On Jan 19, 2015, at 3:26 AM, Akim Demaille wrote:
> 
>> Le 19 janv. 2015 à 09:27, Ryan Schmidt a écrit :
> 
> Hi Ryan,
> 
>> If you mean /opt/local/var/macports/software, that's where the compressed 
>> archives of all your installed ports are stored. You are not meant to 
>> interact with this directory manually. To remove an archive from this 
>> directory, uninstall the corresponding port. If you're still using the port 
>> and don't wish to uninstall it, then you should not delete the corresponding 
>> archive in this directory, or you won't be able to re-activate the port if 
>> you deactivate it. There may be other aspects of MacPorts that also assume 
>> you have not tampered with the contents of this directory.
> 
> Well, I'm a grownup and willing to take these chances.  I don't
> play with activate/deactivate.  I know of no other distros that
> "wastes" that kind of disk space for that.  That some wish to
> use this feature, fine.  But I need those gigs back.

Of note is that MacPorts used to not do this, or rather, using these archives 
used to be optional, and not the default. Previously, the default was that the 
contents of /opt/local/var/macports/software was the actual software being 
installed. Hard links would then be created in the "real" locations. This did 
not waste disk space, however various new features of OS X interacted badly 
with this, including Spotlight as of OS X v10.4 and Time Machine as of OS X 
v10.5, so we were forced to remove the previous mode of operation and insist on 
using archives instead.

I am not familiar with what other package management systems do.


___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Akim Demaille]

> Le 19 janv. 2015 à 09:27, Ryan Schmidt  a écrit :

Hi Ryan,

> If you mean /opt/local/var/macports/software, that's where the compressed 
> archives of all your installed ports are stored. You are not meant to 
> interact with this directory manually. To remove an archive from this 
> directory, uninstall the corresponding port. If you're still using the port 
> and don't wish to uninstall it, then you should not delete the corresponding 
> archive in this directory, or you won't be able to re-activate the port if 
> you deactivate it. There may be other aspects of MacPorts that also assume 
> you have not tampered with the contents of this directory.

Well, I'm a grownup and willing to take these chances.  I don't
play with activate/deactivate.  I know of no other distros that
"wastes" that kind of disk space for that.  That some wish to
use this feature, fine.  But I need those gigs back.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: /opt/local/macports/software

[Ryan Schmidt]

On Jan 19, 2015, at 1:59 AM, Akim Demaille wrote:

> My SSD is short, and this directory currently holds 4.7GB
> of compressed tarballs on my machine.  When I run short of
> space, I remove it.  But why do I have to do that in the
> first place?  There's autoclean in my config file, couldn't
> there be something equivalent to state "I don't want to
> keep these files"?  I really mean something that would be
> obeyed by post install and port upgrade.  Something we
> don't have to think about.
> 
> This is a pretty common wish.  Just ask any search engine
> about "/opt/local/macports/software".

If you mean /opt/local/var/macports/software, that's where the compressed 
archives of all your installed ports are stored. You are not meant to interact 
with this directory manually. To remove an archive from this directory, 
uninstall the corresponding port. If you're still using the port and don't wish 
to uninstall it, then you should not delete the corresponding archive in this 
directory, or you won't be able to re-activate the port if you deactivate it. 
There may be other aspects of MacPorts that also assume you have not tampered 
with the contents of this directory.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

/opt/local/macports/software

[Akim Demaille]

Hi,

My SSD is short, and this directory currently holds 4.7GB
of compressed tarballs on my machine.  When I run short of
space, I remove it.  But why do I have to do that in the
first place?  There's autoclean in my config file, couldn't
there be something equivalent to state "I don't want to
keep these files"?  I really mean something that would be
obeyed by post install and port upgrade.  Something we
don't have to think about.

This is a pretty common wish.  Just ask any search engine
about "/opt/local/macports/software".

Thanks.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users