Joe Peterson schrieb:
> Bernd Steinhauser wrote:
>> And that is, what this is about, making EAPI bumps as less painful as
>> possible. The filename is the easiest solution for that.
>
> In any design, there are "easy" short-cuts that can be taken. But
> sometimes these short-cuts break paradigms that are fundamental. If you
> wanted, you could throw a bunch of things into the filename and make it
> 255 characters long to avoid reading the file, but that clearly would be
> a pretty bad design.
Yes, in principle you could do that, but in principle you could do the
same with the first line in a file or whatever you are suggesting.
>> I really fail to see the point, why it is so important, that the
>> extension will still be .ebuild in the future.
>>
>> There is a lot of software, that keeps using the same filename for
>> different versions of stuff and in many cases, that is a huge mess.
>
> Is the "huge mess" you are thinking of the basic reality that software
> of any reasonable complexity needs to deal with file formats evolving?
> If so, that is exactly why EAPIs now are being introduced.
>
> But almost all software deals with this transparently - no need to
> expose it to the user, and sticking the version in the filename is both
> fragile (renaming the file can alter it) and seems like a hack.
Wow, altering the content of a file can alter it, too. What is the point
there?
BTW, so you are suggesting, that we shouldn't put the PV in the file name?
We shouldn't put the revision in the file name?
Hm, so in the future, there will be a "metadata.xml" file, that defines:
- EAPI
- PV
- KEYWORDS
- more stuff
of the ebuild? Sounds complicated.
>> I still haven't seen any good reasons against it.
>
> I realize that there are two camps of people here. One camp sees
> mangling the filename extension as an undesirable way to deal with this,
> and the other camp simply sees no problem with this.
Seems to be like that.
But I am really impress, how far some people go, to avoid renaming the
file extension of a file.
--
gentoo-dev@g.o mailing list
|