Re: [gentoo-portage-dev] few licences, which should exist
tvali, This does not have anything to do with portage development. While I appreciate your concerns and ideas I must ask you to stop abusing this mailinglist. Things like this off-topic email and the thread where you replied four times to yourself are not good form and should be avoided (unless you really want us to unsubscribe you from this list) Please try to keep your mails on topic and as concise as possible. Thanks, Patrick On Fri, 2006-03-31 at 00:34 +0300, tvali wrote: > (portage list is maybe the best place to send this, but still, maybe > usable as i dont know lists with such specific purpose -- so sending > it to gentoo list and gnu) > > I have thought about such things: > > 1. Formats like mp3 are put together in such way that basically noone > can use them with a free application. There should be licence, which > grants some file formats an opposite -- that no application, which > supports any commercial file format, must not support them. Then > people who want, may put all their free music up in that format -- or > even licence their music in such way that it's only free as long as it > is used together with it. Goal of such licence would be to give gnu > people the same ways to take their market position, as corporations do > -- this may not seem "nice" to those corporations, but it targets the > problem, i think. > > 1a. Licence, which protects a format against being used in any app, > which supports any poorly documented format like MS word document and > by any product by any company, which owns any such format. > > 2. In many countries there are software patents. I think that there > should be licence against them similar to previous licence -- so that > i may patent my free software in such way that any company, which uses > any commercial patent in it's production, must not use that software > [or, as alternative licence, must pay for it to gnu, licence owner or > anyone that patenter sees as deserving it]. So, not "if used in > commercial products", but "if used by commercial company". Patents may > be also used in different ways -- for example, there may be long list > of things a company *must not do* or *must not be*, if they want to > use the patent. > > I think that there are several kinds of people using gnu licences: > * Those, who actually fight against certain types of licences, > corporative policies etc. and want to protect their work against to be > used in any such project -- maybe even in marketing campain of a > corporation, who is "supporting free software" by taking it's code > into use or just supporting it, like IBM with Red Hat. Those people > may, therefore, even want it to be not given away freely with $40 CD > and book. > * Those, who just dont want their code to be used with any direct > commercial purpose and want it to be open, but dont go too far in > philosophy and let their programming language, for example, be used in > making commercial product. > * Those, who want their code to be free and open and any development > to be free and open, but may say something like "wow our soft is used > even in commercial products". > * Those, who just give it for free to students and schools, for > example. > * Those nasty people who make those "free lite versions", which almost > work and spam all search engines ;) > > Ok, my additions here are -- gnu should think more about those people, > who are actually wanting their code to be propagated only by > freeware-makers and run only in environments, which contain no > commercial products and are not used for any commercial purposes. Ok, > they still contain commercial hardware and people may write their > commercial e-mails in them, but anyway, to have a music format, which > licence does it's best to make it so that you have to *choose between > mp3 and mpfree*, not choose between having both or only free one, > would be good. Freeware builders should have at least one "market", > which uses all nasty microsoft-intel trusted corporate policies to > protect itself against everyone other who use them ;) Such > "corporation" could be nice macintosh to other free products, which > are not so radical in their way (ok, what we would eat, when going too > radical, but still -- Microsoft actually *fights* openoffice, so what > having alternative openoffice format, which is, for example, illegal > to be used on commercial OS or, alternatively, illegal to be used in > any application supporting word doc's). > > -- > tvali > > http://www.friesian.com/types.htm -- Stand still, and let the rest of the universe move signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] DB and binary dependency
On Wed, 2006-03-22 at 19:40 +0200, tvali wrote: > I was thinking about it, too, and found something i do like maybe > more. It would be not binary, but code dependancy. This is limited to > specific languages, then, but after all, there may also be different > binary dependencies, too [for example, you may depend on fonts & > images from another package]. > > Ok, my thought is like that. Lets imagine a simple c file: > > #ifdef usepackagex > #include > #endif > > As it is simple to see, this file could be used to calculate > non-binary dependency, inluding useflags. And there is a plus -- tool, > which just reads those #ifdef's and #includes, could easily > understand, which flags make up which dependancy, without building > package again and again with different useflags. There are a few reasons why this won't work :-) First: What if I have assembler? python? perl? Your example is limited to the C preprocessor. Second: You'll have to get this depend information applied by upstream unless you want to patch every file ... and as upstream I'd laugh at anyone proposing that Third: Since there is no easy way of generating this automatically you'll have to replicate every bit of dependency information that is in the ebuilds. That will be much work, you won't keep ebuilds synchronized to the included dep info ... So in short, interesting concept, but I don't see how it can work and how it is an improvement over what we have now. Please don't reinvent the wheel ;-) Patrick -- Stand still, and let the rest of the universe move signature.asc Description: This is a digitally signed message part
[gentoo-portage-dev] Switching LOCALE during build?
Hi all, this is an idea we had at FOSDEM to make bugreports easier to read: During build portage should change the locale to en_us so that any error messages are easy to read even if the user has set it differently. This shouldn't affect users much and could get rid of the bugreports where it is hard to understand what went wrong because everything is in french. Portage changes should be limited to setting LC_ALL in all subshells it spawns. Does this cause any unexpected problems? (Programs changing their language during build would be one possible side-effect). Is it needed/useful? Thanks for any feedback, Patrick -- Stand still, and let the rest of the universe move signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] Deprecating 'emerge action' syntax
On Thu, 2006-02-16 at 19:04 +0100, Marius Mauch wrote: > > If by "deprecate" you mean to detect when '--' hasn't been prepended > > and either go ahead with the action or notify that the package > > doesn't exist then I have no objections. Might be better to go with > > the latter so that users adjust quickly. > > You saw the attached one-line patch? > Atm it just throws a warning when an action without -- is used. > I'm divided on ignoring the action then, on one hand it would be nice to > get rid of this, OTOH it would be kinda rude to not have a transition > period for people. Anyone else having an opinion on this? Don't change it without a longish warning period. Best would be a toggle to warn/fail so that migrating any scripts etc. can be done in a controlled fashion. -- Stand still, and let the rest of the universe move signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] [RFC] making the tree depend on portage
On Mon, 2005-12-19 at 17:49 +0100, Marius Mauch wrote: > Ok, the subject might be confusing, so let me explain this a bit: > > Whenever we want/need to make structural changes to the tree that are > going to break backwards compability we have a serious problem (see > GLEP 44 in case you don't know about it). To reduce the impact of that > problem I've got the idea to make the tree itself (so not any > particular ebuild or profile) DEPEND on a minimal portage version, Makes syncing a bit more complicated. Downside: potentially more problems Upside: if there's a disruptive change people will at all times have a working system (just think about stacked profiles :-) ) > which the users would be forced to upgrade to (maybe with an override) > before they can do anything else (with the exception of --sync). Or you have a "version file" transferred by rsync (like timestamp) When version > portage version: fetch a static portage tree from a known location (mirror://portage-update-version-N.tbz2 or something) (emerge-delta-webrsync to the rescue!) > Manifest2 is one example for such a situation, another one is the > request to not create manifest entries for ChangeLog and metadata.xml > anymore (needs >=2.0.51.20 on user side). > Don't really like this idea myself, but somthing needs to be done to at > least reduce the problem, having to wait years for old portage versions > to (almost) vanish can't be a permanent solution. I don't like it, but unless portage is smart enough to self-update before anything else ... > Also not talking about implementation details yet, just after comments > about the general idea of forced portage updates. If documented properly and guaranteed to work for at least n months after a format change I like it (But I guess iterative updates should work "forever" as long as all files still exist) > And just in case anybody wonders: this cannot be fixed with EAPI or > adding a portage dep on packages as those only take effect when the > ebuild is already parsed while the mentioned problems occur much > earlier. Thanks for bringing it up for discussion! Patrick -- Stand still, and let the rest of the universe move signature.asc Description: This is a digitally signed message part
