2011/6/27 Wyatt Epp :
> 2011/6/27 Jesús J. Guerrero Botella :
>> That still doesn't answer my question anyway: both features (symlinks
>> and +65k files on a single dir) are incompatible with fat32. And
>> someone said fat32 compatibility is a feature we want (still can't
>> guess why, but well, be
Jesús J. Guerrero Botella posted on Mon, 27 Jun 2011 16:19:57 +0200 as
excerpted:
> someone said fat32 compatibility is a feature we want (still can't guess
> why, but well, be consequent...).
I believe that "someone" that mentioned fat32 compatibility in the
context of symlinks was me.
But "
2011/6/27 Jesús J. Guerrero Botella :
> That still doesn't answer my question anyway: both features (symlinks
> and +65k files on a single dir) are incompatible with fat32. And
> someone said fat32 compatibility is a feature we want (still can't
> guess why, but well, be consequent...). Obviously,
2011/6/26 Kent Fredric :
> 2011/6/26 Jesús J. Guerrero Botella :
>> I am really amazed that someone didn't want to use links (a solution
>> with next to zero work involved) because they are not available in
>> fat32 (as if fat32 was relevant at all for us) but then people is
>> suggesting that we s
Kent Fredric posted on Sun, 26 Jun 2011 17:43:27 +1200 as excerpted:
> On 26 June 2011 15:49, Wyatt Epp wrote:
>> As for the latter part, the size of a git repo becoming umanageable
>> over time had not occurred to me, I'm afraid-- would it work to use
>> shallow clones? Otherwise, the herd-wise
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 26-06-2011 12:23, Kent Fredric wrote:
> On 26 June 2011 23:40, Rich Freeman wrote:
>>
>> I think we should avoid changing the fundamental design of portage,
>> such as removing categories or allowing tags to be used as
>> dependencies/etc. At le
On Sun, 26 Jun 2011 22:13:24 +1200
Kent Fredric wrote:
> With this "new" system however, pkgmoves will be a thing of the past,
> even if we keep the legacy category system around.
Nope. Package names can still change, and I really dislike the idea of
keeping some magical hashes or deprecated nam
On 26 June 2011 23:40, Rich Freeman wrote:
>
> I think we should avoid changing the fundamental design of portage,
> such as removing categories or allowing tags to be used as
> dependencies/etc. At least, not right now. If we set up namespaces
> for tags that might allow for such a thing in the
On Sun, Jun 26, 2011 at 5:53 AM, Patrick Lauer wrote:
> So again, what are you trying to fix, and what makes you think it was
> broken to start with?
Well, I think there are things worth improving. However, I'm not sure
that we should consider implementation of tagging a reason to
re-design the
On 26 June 2011 21:53, Patrick Lauer wrote:
>
> I disagree. If I put postgresql in x11-libs that's just wrong, and then
> you fix it with a package move. Doesn't mean the category system is
> broken, just means that it was in the wrong place at the wrong time.
>
>>
>> As far as app-xemacs is conce
On 06/25/11 21:42, Maciej Mrozowski wrote:
> On Saturday 25 of June 2011 19:29:58 Ulrich Mueller wrote:
>>> On Sat, 25 Jun 2011, Maciej Mrozowski wrote:
>>> Assuming package names are unique identifiers, tags are not
>>> necessary to be available for ebuild.sh so metadata.xml is the best
>>> pl
2011/6/26 Jesús J. Guerrero Botella :
> I am really amazed that someone didn't want to use links (a solution
> with next to zero work involved) because they are not available in
> fat32 (as if fat32 was relevant at all for us) but then people is
> suggesting that we should put everything into a fla
I am really amazed that someone didn't want to use links (a solution
with next to zero work involved) because they are not available in
fat32 (as if fat32 was relevant at all for us) but then people is
suggesting that we should put everything into a flat folder and use
tags. Well, good look getting
On 26 June 2011 15:49, Wyatt Epp wrote:
> As for the latter part, the size of a git repo becoming umanageable
> over time had not occurred to me, I'm afraid-- would it work to use
> shallow clones? Otherwise, the herd-wise division is probably
> acceptable. Need to think about that one more.
On Sat, Jun 25, 2011 at 21:47, Kent Fredric wrote:
> Package names themselves can be thusly arbitrary , and could be a SHA
> sum or something obscure, as long as all internals and dependencies
> used the same arbitrary name, things would work as intended.
>
I mentioned this idea of internally refe
On 26 June 2011 05:29, Ulrich Mueller wrote:
>> On Sat, 25 Jun 2011, Maciej Mrozowski wrote:
>
>> Assuming package names are unique identifiers, tags are not
>> necessary to be available for ebuild.sh so metadata.xml is the best
>> place.
>
> But we know that package names are _not_ unique. Th
On Saturday 25 of June 2011 19:29:58 Ulrich Mueller wrote:
> > On Sat, 25 Jun 2011, Maciej Mrozowski wrote:
> > Assuming package names are unique identifiers, tags are not
> > necessary to be available for ebuild.sh so metadata.xml is the best
> > place.
>
> But we know that package names are
> On Sat, 25 Jun 2011, Maciej Mrozowski wrote:
> Assuming package names are unique identifiers, tags are not
> necessary to be available for ebuild.sh so metadata.xml is the best
> place.
But we know that package names are _not_ unique. There are many cases
in the Portage tree where two or ev
On Saturday 25 of June 2011 17:19:47 Duncan wrote:
> Maciej Mrozowski posted on Sat, 25 Jun 2011 13:55:40 +0200 as excerpted:
> > On Friday 24 of June 2011 09:55:19 Ciaran McCreesh wrote:
> >> So tags are in some way related to categories then?
> >
> > IMHO the best approach is to forget about cat
Maciej Mrozowski posted on Sat, 25 Jun 2011 13:55:40 +0200 as excerpted:
> On Friday 24 of June 2011 09:55:19 Ciaran McCreesh wrote:
>> So tags are in some way related to categories then?
>
> IMHO the best approach is to forget about categories and:
>
> - make package names unique identifiers (
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 06/22/2011 05:18 AM, Kent Fredric wrote:
> On 22 June 2011 08:37, Michał Górny wrote:
>>> Right. mplayer, xine, etc, work just fine as for instance mp3
>>> players. So media- is fine for them.
>>
>> But probably we'll move it into media-play
On Thu, 23 Jun 2011 11:08:35 +0200
Jesús J. Guerrero Botella wrote:
> But it's also true that besides the symlinks, the portage tree will
> be broken the same moment you put it into a fat volume, because it
> will directly erase all the permissions and ownership metadata.
Those don't matter to a
2011/6/23 Duncan <1i5t5.dun...@cox.net>:
> Jesús J. Guerrero Botella posted on Thu, 23 Jun 2011 08:15:44 +0200 as
> excerpted:
>
>> Symlinks are clean, and portage has always been file-oriented so I see
>> no problem with using them for this.
>
> It has been some years since I've seen the argument
Jesús J. Guerrero Botella posted on Thu, 23 Jun 2011 08:15:44 +0200 as
excerpted:
> Symlinks are clean, and portage has always been file-oriented so I see
> no problem with using them for this.
It has been some years since I've seen the argument made, but if I'm not
mistaken, at least back in 20
On Wed, 22 Jun 2011 21:18:26 +1200
Kent Fredric wrote:
> incidentally, I'd be in favour of splitting mplayer and mencoder into
> seperate dists if it were sanely plausible to do so.
A same thing would be great, say, for ffmpeg. Right now we just have
USE=encode which enable all encoder dependenc
On 22 June 2011 08:37, Michał Górny wrote:
>> Right. mplayer, xine, etc, work just fine as for instance mp3
>> players. So media- is fine for them.
>
> But probably we'll move it into media-players and so on then.
mplayer and some other things most-often used for playback might be a
bit of a
audio-* sound better.
graphics-* sounds better, if I suggested gfx it was just it's how we
have it now in media-gfx (I never liked that either).
I also think that media-* can stay. So, something like this would be
closer, I guess.
graphics-viewers
graphics-editors
graphics-plugins
graphics-libs
a
Michał Górny posted on Tue, 21 Jun 2011 22:37:46 +0200 as excerpted:
>> IMO gfx- looks like some texting/personal shortcut,
>> not appropriately professional for a (meta-)distro like gentoo.
>
> Like in 'media-gfx'? :P
The initial gfx is rather worse, but yes. Just as the devmanual states
On Tue, 21 Jun 2011 20:29:23 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:
> >> gfx-viewers gfx-editors gfx-plugins gfx-libs sound-players
> >> sound-radio? sound-editors sound-plugins sound-libs video-players
> >> video-tv? video-editors video-plugins video-libs
> >
> > I think 'audio' works
Steve Dibb posted on Tue, 21 Jun 2011 09:55:08 -0600 as excerpted:
> On 06/21/2011 08:40 AM, Jesús J. Guerrero Botella wrote:
>> 2011/6/21 Michał Górny:
>>> media-sound/ category has grown very large and [could be split].
>>> [I]t contains audio players, editing software, converters,
>>> sound sy
30 matches
Mail list logo
