FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 02-19-2009, 09:03 PM
Ulrich Mueller
 
Default Proposal for compression handling

>>>>> On Thu, 19 Feb 2009, Ciaran McCreesh wrote:

> If there's an inclusion list and an exclusion list, there's only a
> need to delete things from the exclusion list if the exclusion list
> has bad initial values, and never any need to delete things from the
> inclusion list. And since reliably rewriting links in HTML when
> compressing is at best tricky and at worst impossible (think
> JavaScript navigationy things), is there ever going to be any need
> for removing from the exclusion list?

Right, probably there isn't. So we will need only two options:

- "docompress" (without option or with option "-a"): add paths
(directories or files) to the inclusion list
- "docompress -x": add paths to the exclusion list

Ulrich
 
Old 02-20-2009, 06:42 AM
Brian Harring
 
Default Proposal for compression handling

On Thu, Feb 19, 2009 at 11:03:28PM +0100, Ulrich Mueller wrote:
> >>>>> On Thu, 19 Feb 2009, Ciaran McCreesh wrote:
>
> > If there's an inclusion list and an exclusion list, there's only a
> > need to delete things from the exclusion list if the exclusion list
> > has bad initial values, and never any need to delete things from the
> > inclusion list. And since reliably rewriting links in HTML when
> > compressing is at best tricky and at worst impossible (think
> > JavaScript navigationy things), is there ever going to be any need
> > for removing from the exclusion list?
>
> Right, probably there isn't. So we will need only two options:
>
> - "docompress" (without option or with option "-a"): add paths
> (directories or files) to the inclusion list
> - "docompress -x": add paths to the exclusion list

Globbing support? Also I assume compliant implementations do their
updating between install/preinst?

~harring
 
Old 02-20-2009, 06:59 AM
Ulrich Mueller
 
Default Proposal for compression handling

>>>>> On Thu, 19 Feb 2009, Brian Harring wrote:

>> - "docompress" (without option or with option "-a"): add paths
>> (directories or files) to the inclusion list
>> - "docompress -x": add paths to the exclusion list

> Globbing support?

No, I would say. The other do* commands don't have it, and
"docompress -x foo*" will work anyway since the argument is expanded
before calling the function.

> Also I assume compliant implementations do their updating between
> install/preinst?

Indeed, that's what I meant. ;-) Thanks.

Ulrich
 
Old 02-21-2009, 10:09 PM
Zac Medico
 
Default Proposal for compression handling

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ulrich Mueller wrote:
>>>>>> On Thu, 19 Feb 2009, Brian Harring wrote:
>
>>> - "docompress" (without option or with option "-a"): add paths
>>> (directories or files) to the inclusion list
>>> - "docompress -x": add paths to the exclusion list
>
>> Globbing support?
>
> No, I would say. The other do* commands don't have it, and
> "docompress -x foo*" will work anyway since the argument is expanded
> before calling the function.

Keep in mind that using a glob that way is going to mean that
docompress has to join each path with the current directory and then
strip $D from the left side. Doing it that way complicates the
implementation details a bit, and it's not quite as flexible as
regular expression support would be. With regular expression support
you could even control which file extensions are compressed or not.
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)

iEYEARECAAYFAkmgibEACgkQ/ejvha5XGaO3IwCfW+qTR7yMYo1D7XYk6QnUsM+s
4hYAoL4efSmN/xxZog1RGLuWtIqaN/h3
=YWcZ
-----END PGP SIGNATURE-----
 
Old 02-22-2009, 08:57 AM
Ulrich Mueller
 
Default Proposal for compression handling

>>>>> On Sat, 21 Feb 2009, Zac Medico wrote:

> Keep in mind that using a glob that way is going to mean that
> docompress has to join each path with the current directory and
> then strip $D from the left side. Doing it that way complicates the
> implementation details a bit, and it's not quite as flexible as
> regular expression support would be. With regular expression support
> you could even control which file extensions are compressed or not.

Following our discussion in #-portage and after thinking about it:
I assume that there would be very few cases where globbing or regexp
support is required. And these could always be handled by the ebuild
itself or by an eclass function.

So, we should follow the KISS principle here, and allow only literal
paths (files or directories) as arguments for docompress.

Ulrich
 

Thread Tools




All times are GMT. The time now is 07:16 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org