5 ms·

Please read the link. Reproducible Builds has standardized "SOURCE_DATE_EPOCH" for exactly this usecase. Introducing other variable names i just going to cause

Please read the link. Reproducible Builds has standardized "SOURCE_DATE_EPOCH" for exactly this usecase. Introducing other variable names i just going to cause more problems. https://reproducible-builds.org/docs/source-date-epoch/ https://reproducible-builds.org/docs/source-date-epoch/

ainar-g 5y ago
My message was more about how you don't necessarily need to exclude the date information as opposed to exact variable names. But thanks for the info.
jatone 5y ago
no its not. build tools can use whatever names they want for environment variables. sharing tends to cause more issues then having namespaced ones due to unintended side effects.
laumars 5y ago
It’s a proposed convention. A specification. But it’s not a standard.
- capableweb 5y ago
  Foxboron wrote "Reproducible Builds has standardized". Going to the website, they write "SOURCE_DATE_EPOCH is a standardised environment variable" and it links to https://reproducible-builds.org/specs/source-date-epoch/ https://reproducible-builds.org/specs/source-date-epoch/ which is a specification to standardize something. So it's accurate to say that "Reproducible Builds has standardized" that since they only talk about their own organization, not that it has been accepted to IETF or something like that.
  - Foxboron 5y ago
    Man, if people just took the time to read the link and not the comment :)
    - password4321 5y ago
      It usually takes less than 30 seconds to copy+paste quote the portion of the linked content that's actually relevant. Doing so greatly improves the effectiveness of communication.
    - laumars 5y ago
      I actually did and the link just references a specification, not a standard. Something being “standardised” requires more than just a specification and just because the specification throws the term “standard” around it doesn’t mean it has been formally standardised. This doesn’t mean people shouldn’t still follow the specification. Plenty of specifications exist that have not been standardised. For example, there is an RFC specification for CSVs but not formal standard. So by all means push this specification as a de facto standard but please don’t mislead people saying it has been standardised when it has not.
  - laumars 5y ago
    That’s a specification. Just because the specification says it’s standardised it doesn’t mean it is. Where’s the corresponding approval from ISO, ANSI or other standards authority? There’s nothing wrong with a specification or even a reference implementation but they are not themselves standards. And that’s exactly what this is: a widely respected specification. You shouldn’t have to lie about this being standardised for it still to be relevant.
    - capableweb 5y ago
      You don't need to get approval from ISO, ANSI or any other entity in order to standarize something _within your own organization_. Again, the SOURCE_DATE_EPOCH variable has been standarized within the Reproducible Builds organization, and no one can say otherwise.
      - laumars 5y ago
        But that doesn’t still make the specification “standardised” for anyone else. I hate arguing semantics because it’s usually a worthless argument. But the problem here is people are specifically arguing that Reproducible Builds have standardised something when they have not. If you still want to use their specification then that’s grand. You don’t need a specification standardised for it to be relevant. However on the very specific point of whether this is a standard, I’m yet to see any proof that anyone has actually standardised the specification. All I’m reading is “but they say it is” and frankly that’s not enough to make a standard.
        Foxboron 5y ago
        I wrote "Reproducible Builds has standardized". I made no assertions how this is recognized in the wider ecosystem. However, a couple hundred projects heed this standard along with most distributions. Does your nitpicking really matter?
        laumars 5y ago
        It does when you tersely react to other people’s comments stating they should follow “standards” (which you now finally agree are not a standard). If your comment wasn’t so rude from the outset then I wouldn’t have nitpicked your statement. I think there’s some “law” people often quite about people who correct other people that applies to your post.
- cpuguy83 5y ago
  It's used by rpmbuild and dpkg-buildpackage (and The stuff underneath). That's pretty well standardized.
  - laumars 5y ago
    No, that makes it a common implementation or even a de facto standard. It does not make it standardised because Reproducible Builds is not a recognised standards authority.
    - diabonas 5y ago
      There is no such thing as a "recognised standards authority". Who would be the root standards authority to appoint other standards authorities? ;) And why can't the Reproducible Builds project be one of them?
      - laumars 5y ago
        > There is no such thing as a "recognised standards authority". Yes there is > Who would be the root standards authority to appoint other standards authorities? You’re thinking of signing authorities. > And why can't the Reproducible Builds project be one of them? You could also flip The argument on its head and say why should every committee that throws a specification up be considered a standards authority when half the time specifications are incomplete, contradict other specifications or flat out don’t work. Anyway, I’ll make this my last post on the subject. I have no interest to waste any more time explaining the difference between a standard and a specification to people who are unwilling to consider there might be a difference.
        diabonas 5y ago
        > Yes there is > You’re thinking of signing authorities. No, I don't. I was asking for a list of authorities that you would consider authoritative (which invariably will be subjective, but would be interesting nonetheless). > You could also flip The argument on its head and say why should every committee that throws a specification up be considered a standards authority when half the time specifications are incomplete, contradict other specifications or flat out don’t work. Oh sure, specifications always suck™. But that is unfortunately quite independent from the organisation, happens all the time with ISO standards, IETF RFCs, or whatever you would consider "recognised" bodies. > I have no interest to waste any more time explaining the difference between a standard and a specification to people who are unwilling to consider there might be a difference. You haven't explained anything. All you have been saying in this thread is "I don't recognise the Reproducible Builds project as a standards authority, because I only believe in my personal list of authorities that I won't reveal". The point is, a standard does not become a standard because it is published by a "competent authority". A standard becomes a standard when people in the respective field converge on using it. And yes, there are of course certain fields where this convergence can be enforced e.g. through local law, professional associations etc. However, software development is generally not one of these fields: who will reprimand you if you write a C compiler that does not follow ISO/IEC 9899, or in this case one that does not respect SOURCE_DATE_EPOCH?
- IshKebab 5y ago
  Why would you not follow their convention? That's how we've ended up with CLICOLOR and NO_COLOR. The NO_COLOR guy decided "nah it's not a standard". :/
  - laumars 5y ago
    You’ve missed the point. I’m not saying we shouldn’t have a specification not an agreed convention. I’m saying the GP shouldn’t get so argumentative about Reproducible Builds being a standard when it’s just a specification.

ainar-g 5y ago

My message was more about how you don't necessarily need to exclude the date information as opposed to exact variable names. But thanks for the info.

jatone 5y ago

no its not. build tools can use whatever names they want for environment variables. sharing tends to cause more issues then having namespaced ones due to unintended side effects.

laumars 5y ago

It’s a proposed convention. A specification. But it’s not a standard.

capableweb 5y ago
Foxboron wrote "Reproducible Builds has standardized". Going to the website, they write "SOURCE_DATE_EPOCH is a standardised environment variable" and it links to https://reproducible-builds.org/specs/source-date-epoch/ https://reproducible-builds.org/specs/source-date-epoch/ which is a specification to standardize something. So it's accurate to say that "Reproducible Builds has standardized" that since they only talk about their own organization, not that it has been accepted to IETF or something like that.
- Foxboron 5y ago
  Man, if people just took the time to read the link and not the comment :)
  - password4321 5y ago
    It usually takes less than 30 seconds to copy+paste quote the portion of the linked content that's actually relevant. Doing so greatly improves the effectiveness of communication.
  - laumars 5y ago
    I actually did and the link just references a specification, not a standard. Something being “standardised” requires more than just a specification and just because the specification throws the term “standard” around it doesn’t mean it has been formally standardised. This doesn’t mean people shouldn’t still follow the specification. Plenty of specifications exist that have not been standardised. For example, there is an RFC specification for CSVs but not formal standard. So by all means push this specification as a de facto standard but please don’t mislead people saying it has been standardised when it has not.
- laumars 5y ago
  That’s a specification. Just because the specification says it’s standardised it doesn’t mean it is. Where’s the corresponding approval from ISO, ANSI or other standards authority? There’s nothing wrong with a specification or even a reference implementation but they are not themselves standards. And that’s exactly what this is: a widely respected specification. You shouldn’t have to lie about this being standardised for it still to be relevant.
  - capableweb 5y ago
    You don't need to get approval from ISO, ANSI or any other entity in order to standarize something _within your own organization_. Again, the SOURCE_DATE_EPOCH variable has been standarized within the Reproducible Builds organization, and no one can say otherwise.
    - laumars 5y ago
      But that doesn’t still make the specification “standardised” for anyone else. I hate arguing semantics because it’s usually a worthless argument. But the problem here is people are specifically arguing that Reproducible Builds have standardised something when they have not. If you still want to use their specification then that’s grand. You don’t need a specification standardised for it to be relevant. However on the very specific point of whether this is a standard, I’m yet to see any proof that anyone has actually standardised the specification. All I’m reading is “but they say it is” and frankly that’s not enough to make a standard.
      - Foxboron 5y ago
        I wrote "Reproducible Builds has standardized". I made no assertions how this is recognized in the wider ecosystem. However, a couple hundred projects heed this standard along with most distributions. Does your nitpicking really matter?
        laumars 5y ago
        It does when you tersely react to other people’s comments stating they should follow “standards” (which you now finally agree are not a standard). If your comment wasn’t so rude from the outset then I wouldn’t have nitpicked your statement. I think there’s some “law” people often quite about people who correct other people that applies to your post.
cpuguy83 5y ago
It's used by rpmbuild and dpkg-buildpackage (and The stuff underneath). That's pretty well standardized.
- laumars 5y ago
  No, that makes it a common implementation or even a de facto standard. It does not make it standardised because Reproducible Builds is not a recognised standards authority.
  - diabonas 5y ago
    There is no such thing as a "recognised standards authority". Who would be the root standards authority to appoint other standards authorities? ;) And why can't the Reproducible Builds project be one of them?
    - laumars 5y ago
      > There is no such thing as a "recognised standards authority". Yes there is > Who would be the root standards authority to appoint other standards authorities? You’re thinking of signing authorities. > And why can't the Reproducible Builds project be one of them? You could also flip The argument on its head and say why should every committee that throws a specification up be considered a standards authority when half the time specifications are incomplete, contradict other specifications or flat out don’t work. Anyway, I’ll make this my last post on the subject. I have no interest to waste any more time explaining the difference between a standard and a specification to people who are unwilling to consider there might be a difference.
      - diabonas 5y ago
        > Yes there is > You’re thinking of signing authorities. No, I don't. I was asking for a list of authorities that you would consider authoritative (which invariably will be subjective, but would be interesting nonetheless). > You could also flip The argument on its head and say why should every committee that throws a specification up be considered a standards authority when half the time specifications are incomplete, contradict other specifications or flat out don’t work. Oh sure, specifications always suck™. But that is unfortunately quite independent from the organisation, happens all the time with ISO standards, IETF RFCs, or whatever you would consider "recognised" bodies. > I have no interest to waste any more time explaining the difference between a standard and a specification to people who are unwilling to consider there might be a difference. You haven't explained anything. All you have been saying in this thread is "I don't recognise the Reproducible Builds project as a standards authority, because I only believe in my personal list of authorities that I won't reveal". The point is, a standard does not become a standard because it is published by a "competent authority". A standard becomes a standard when people in the respective field converge on using it. And yes, there are of course certain fields where this convergence can be enforced e.g. through local law, professional associations etc. However, software development is generally not one of these fields: who will reprimand you if you write a C compiler that does not follow ISO/IEC 9899, or in this case one that does not respect SOURCE_DATE_EPOCH?
IshKebab 5y ago
Why would you not follow their convention? That's how we've ended up with CLICOLOR and NO_COLOR. The NO_COLOR guy decided "nah it's not a standard". :/
- laumars 5y ago
  You’ve missed the point. I’m not saying we shouldn’t have a specification not an agreed convention. I’m saying the GP shouldn’t get so argumentative about Reproducible Builds being a standard when it’s just a specification.